先に要点
- Fly.io は、Dockerfile から作ったコンテナを世界 30 以上のリージョンの軽量 VM(Firecracker microVM)として配置し、ユーザーに近い場所で実行する アプリ実行基盤(PaaS)。「グローバルに分散した自分専用の小さなサーバ群」 を、コマンド数本で立ち上げられる。
- エッジで動くのは静的配信や軽い関数だけではない。Fly.io は 常駐プロセス・WebSocket・バックグラウンドジョブ・データベースまで含めて エッジ寄りに置ける点が、Cloudflare Workers や Vercel Edge と決定的に違う。
- 料金は 固定月額プランを廃した完全従量制。小さな常時起動アプリで月数ドル、停止可能な構成ならさらに安い。最新の単価は必ず公式の料金ページで確認する。
- 使いどころは 地理的に分散したユーザーへ低遅延で返したい常駐型アプリ・WebSocket やゲーム系・自前 Docker をそのまま動かしたい ケース。逆に静的サイト中心や 「とにかく無料で始めたい」 用途では Vercel や Cloudflare のほうが向くことも多い。
「Fly.io ってよく名前は聞くけど、Vercel や Cloudflare と何が違うの？」 「エッジで動くって、結局 Workers みたいなもの？」 「料金は安いの、高いの？」 ── Fly.io は、Docker コンテナを世界中のエッジに近い場所で 「ちゃんとした VM」 として動かせる実行基盤として、Web 開発者やスタートアップから根強い支持を集めています。
ざっくり言うと、Fly.io は Dockerfile から作ったアプリを、世界 30 以上の地域にある軽量 VM として配置し、ユーザーに最も近い場所で実行する PaaS です。サーバレス系のエッジ実行基盤と違い、常駐プロセスやデータベースまで含めてエッジ寄りに置ける のが最大の特徴です。
この記事では、2026年6月時点の情報をベースに、Fly.io とは何か・できること・料金・使いどころ・他の PaaS やエッジ系との違い を実務目線で整理します。単価やプラン構成は変動するため、最終的な金額は 公式の料金ページ で必ず確認してください。
Fly.io とは — 「グローバルに散らばった小さな VM 群」
Fly.io を一言で表すと、「Docker コンテナを世界中に分散した軽量 VM として動かすアプリ実行基盤」 です。
中核にあるのが Fly Machines と呼ばれる仕組みで、これは Firecracker という軽量仮想化技術で作られた microVM(マイクロ VM)です。Firecracker は AWS Lambda の裏側でも使われている技術で、秒未満で起動・停止でき、コンテナ並みに軽いのに 独立した VM としての強い分離 を持ちます。
入力は Dockerfile
多くのアプリは Dockerfile から起動できる。普段 Docker でローカル開発しているなら、ほぼそのまま乗せられるのが強み。「専用フレームワークに書き換える」 必要がない。
実体は microVM
動くのは関数ではなく 独立した小さな VM。だから常駐プロセス・SSH・任意のポート・好きな言語が普通に使える。「サーバを借りた」 感覚に近い。
グローバル分散
世界 30 以上のリージョンに配置可能。Anycast ネットワーク がリクエストを最寄りのインスタンスへ自動で振り分ける。東京・サンパウロ・アムステルダムの利用者が、それぞれ近い VM に届く。
面倒は肩代わり
TLS 終端(TLS Termination)・証明書・ルーティング・ヘルスチェックはプラットフォーム側が処理。開発者は VM の中身に集中できる。
「VPS をグローバルに散りばめて、ルーティングと証明書だけ自動化してくれたもの」 と捉えると、感覚的に近いです。VPS や コンテナ の延長線上にありながら、配置と運用の手間を大きく減らしているのが Fly.io の立ち位置です。
Fly.io でできること — エッジで動かせる範囲が広い
エッジ実行基盤というと、CDN のように静的ファイルを配るイメージや、軽量な関数を動かす用途を思い浮かべがちです。Fly.io が面白いのは、その範囲をかなり広く取っている 点です。
- 常駐型の Web アプリ: Rails / Django / Laravel / Express / Go / Phoenix など、Dockerfile にできるものはほぼ何でも。フレームワークを問わない。
- WebSocket・リアルタイム通信: 接続を維持し続ける用途に強い。チャット、共同編集、ゲームのマッチング系など。関数型サーバレスが苦手な領域。
- バックグラウンドワーカー・ジョブ処理: Web とは別に常駐ワーカーを置ける。ジョブキュー を回す構成も自然。
- データベース: PostgreSQL や Redis 互換のデータストアをアプリの近くに配置できる。アプリとデータを同じ地域に置けるのは遅延面で大きい。
- 自動停止・自動起動: アイドル時に Machine を止め、次のリクエストで起こす設定が可能。サーバレス的なコスト削減を、フル VM のまま得られる。
スケールの考え方
「リージョンを足す」 「各リージョンの台数を増やす」 という、サーバ台数に近い直感的なスケール。Kubernetes ほどの学習コストはかからない。
要するに Fly.io は、「普通のサーバアプリを、世界中のユーザーの近くで動かす」 ことを得意とします。エッジ = 軽い関数だけ、という先入観を持っていると、できることの広さで驚くはずです。
始め方 — Dockerfile があれば数コマンド
実際の導入は、コンテナに慣れていれば拍子抜けするほど短い手順です。CLI(flyctl)を入れて、アプリを作り、デプロイする、という流れになります。
つまずきやすいのは次の点です。Dockerfile が用意できない、あるいはコンテナの基礎が曖昧 なまま始めると、ビルドエラーやポート設定で手が止まりがちです。まずは コンテナの基礎 と Dockerfile の書き方 を押さえておくと、Fly.io の体験は一気にスムーズになります。
もう一つは 「どのリージョンに何台置くか」 の設計です。最初から全世界に展開すると、台数ぶんだけ課金が増えます。まずは利用者が多い1〜2地域に絞り、遅延の実測を見てから広げるのが堅実です。
Fly.io の料金 — 完全従量制を理解する
Fly.io は 2024 年以降、Hobby / Launch / Scale といった 固定月額プランを廃止 し、使ったぶんだけ秒単位で課金する従量制 に一本化しました。「プランを選ぶ」 のではなく 「動かしたリソースの合計が請求になる」 と理解するのが出発点です。
以下は 2026年6月時点で確認できた代表的な単価の目安です。リージョンや為替で変わり、頻繁に改定されるため、必ず公式の料金ページで最新を確認してください。
| 項目 | 単価の目安(2026年6月時点) | 補足 |
|---|---|---|
| shared-cpu-1x / 256MB | 約 2 ドル/月(常時起動) | 最小構成。秒課金なので止めればさらに下がる |
| shared-cpu-2x / 512MB | 約 4 ドル/月(常時起動) | 小さめの常駐アプリ向け |
| performance-1x / 2GB | 約 32 ドル/月(常時起動) | 専有 CPU。CPU を使う処理向け |
| ボリューム(永続ディスク) | 約 0.15 ドル/GB・月 | 確保した容量に対して課金 |
| 下り通信(北米・欧州) | 約 0.02 ドル/GB | 地域により単価が上がる(アジア・南米はより高い) |
| サポートプラン | 月 29 ドル〜(上位は 199 ドル〜) | SLA 付きの有償サポートは別建て |
ここで実務上の注意点が3つあります。
無料枠は実質的に廃止された
かつての手厚い無料枠は終了し、新規は短いトライアル(VM 稼働時間ぶんなど)に置き換わっている。「無料でずっと運用」 を前提にすると当てが外れる。最新の扱いは公式で確認を。
下り通信と多リージョンで膨らむ
地域を増やすほど常駐台数が増え、通信単価も地域差がある。下り通信(egress)コスト は見落としやすい。請求書の内訳を定期的に見る習慣を。
総じて、小さな常駐アプリを1〜2リージョンで動かすぶんには月数ドル〜十数ドル に収まり、コスト効率は良好です。一方で 「無料で気軽に試す」 用途や、台数を多リージョンに広げる構成では、思ったより請求が伸びることがあります。最新の料金体系は 公式の料金ページ で確認するのが鉄則です。
他の PaaS・エッジ系との違い
Fly.io の立ち位置は、「サーバレス型のエッジ実行基盤」 と 「従来型の PaaS / VPS」 のちょうど中間にあります。代表的な選択肢と比べると輪郭がはっきりします。
| サービス | 実行モデル | 得意なこと | 主な制約 |
|---|---|---|---|
| Fly.io | Docker → 軽量 VM をグローバル配置 | 常駐アプリ・WebSocket・DB をエッジ寄りに。フル VM の自由度 | 無料枠が薄い。多リージョンで運用設計が必要 |
| Cloudflare Workers | V8 isolates の関数 | Cold start ゼロの軽量関数。手厚い無料枠 | 常駐プロセス不可。Node API に制約 |
| Vercel | フロント特化のサーバレス | Next.js などのフロント配信・プレビュー | 常駐サーバや自前 DB 配置には不向き |
| 従来型 PaaS / VPS | 固定サーバ・コンテナ | シンプルな単一地域運用 | グローバル低遅延は自前で構築が必要 |
ポイントは 「エッジで何を動かすか」 の違いです。Cloudflare Workers や Vercel のエッジは 「軽い処理を世界中で即実行」 することに最適化されており、常駐プロセスや独自ミドルウェア、近接配置の DB といった重めの構成は苦手です。Fly.io は逆に、「普通のサーバアプリ一式」 をまるごとグローバルに置ける ことを売りにしています。
選び方の軸はこう整理できます。
- 静的サイト・フロント中心 + 軽い API → Vercel / Cloudflare 系が素直。無料枠も活きる。
- 軽量関数を世界中で大量に実行 → Cloudflare Workers が強い。Cold start ゼロが効く。
- 常駐サーバ・WebSocket・自前 DB をグローバルに低遅延で → Fly.io が刺さる。
- 単一地域で素朴に動けば十分 → わざわざグローバル基盤を使わず、VPS や従来型 PaaS で足りることも多い。
より広い俯瞰は デプロイ基盤の比較 や、コンテナ・サーバレス・VM の比較 も合わせて読むと、判断軸が立てやすくなります。
どんな案件で選び、どんな案件で避けるか
最後に、実務での採用判断をはっきりさせておきます。
選ぶと良い案件
世界の複数地域に利用者がいて低遅延が欲しい/WebSocket やリアルタイム性が要る/自前 Docker をそのまま動かしたい/アプリと DB を近接させたい、といったケース。「VPS をグローバル化したい」 が当てはまるなら有力。
避けたほうが良い案件
とにかく無料で始めたい/静的サイトや軽い API だけ/利用者が1地域に集中/運用に人手をかけられない、といったケース。Vercel・Cloudflare や素の VPS のほうが安く簡単に済むことが多い。
移行を考えるとき
単一 VPS で遅延や可用性に限界を感じ始めたら検討の好機。判断軸は VPS からクラウドへ移行する基準 も参考になる。
迷ったら、「常駐プロセスとデータを、世界中の利用者の近くに置きたいか」 を自問してください。答えが Yes なら Fly.io は強力な候補です。No なら、もっと手軽で安い選択肢で十分なことがほとんどです。
Fly.io に関するよくある質問
Q. Fly.io はサーバレスですか、それとも VPS ですか。
A. どちらでもなく中間です。実体は 独立した軽量 VM(microVM) なので VPS に近い自由度がありますが、配置・ルーティング・証明書・自動停止/起動はプラットフォームが面倒を見るため、運用感はサーバレスに寄ります。「グローバルに分散した、運用が自動化された VPS」 が一番近い理解です。
Q. Cloudflare Workers との一番大きな違いは何ですか。
A. 常駐プロセスとフル VM が使えるかどうか です。Workers は V8 isolates 上の軽量関数で、常駐や一部の OS 機能は使えません。Fly.io は普通のサーバプロセスをそのまま動かせ、WebSocket や自前ミドルウェア、近接配置の DB まで扱えます。
Q. 無料で使えますか。
A. かつての常時無料枠は実質的に終了し、現在は短いトライアル中心です。本番運用は従量課金が前提と考えてください。「ずっと無料」 を求めるなら、無料枠の手厚い Cloudflare 系のほうが向きます。最新の扱いは公式の料金ページで確認してください。
Q. 小さなアプリだといくらくらいになりますか。
A. 最小構成(shared-cpu-1x / 256MB)を1リージョンで常時起動すると月2ドル前後が目安です。ここにボリュームや下り通信、追加リージョンが乗ると増えます。台数と地域を絞れば数ドル〜十数ドルに収まりやすいです。
Q. Dockerfile がないと使えませんか。
A. 多くの言語・フレームワークでは fly launch が自動でビルド設定を用意 してくれるため、必ずしも自分で書く必要はありません。ただし挙動を制御したい本番運用では、Dockerfile を理解しておくとトラブル対応が楽になります。
Q. データベースはどうしますか。
A. Fly.io 上に PostgreSQL や Redis 互換のデータストアを アプリと同じ地域に配置 できます。アプリと DB を近づけられるため、関数型エッジでありがちな 「処理は近いが DB が遠い」 問題を避けやすいのが利点です。運用責任の範囲は事前に確認してください。
Q. 日本のユーザー向けにも使えますか。
A. はい。東京を含むアジア圏のリージョンが利用でき、Anycast が最寄りへ振り分けます。ただし下り通信単価は地域差があり、アジアは北米・欧州より高めの傾向です。日本中心ならまず1リージョンで始め、実測しながら広げるのが無難です。