PaaS 比較 2026 — Vercel · Netlify · Render · Fly.io · Railway · Northflank · Heroku · Cloud Run · App Runner · Coolify どこにデプロイすべきか正面比較

• プロローグ — Heroku が去った席に誰が座ったのか
• 1 章. PaaS の定義 — 何が PaaS で何がそうでないか
  • 1.1 PaaS の五つの軸
• 2 章. Vercel — Next.js の本家、そして v0 まで
  • 2.1 Vercel に Next.js + Postgres + Redis をデプロイ
  • 2.2 Vercel の適合領域
• 3 章. Netlify — Vercel の兄、生き残った兄
• 4 章. Render — 「Heroku が恋しい? 俺たちが Heroku だ」
  • 4.1 Render に Next.js + Postgres + Redis + Worker をデプロイ
• 5 章. Fly.io — Docker ファースト、グローバルファースト
  • 5.1 Fly の真の強み — マルチリージョンが些細
• 6 章. Railway — 分単位リソース、美しい UX
  • 6.1 Railway の魅力 — コードなしインフラ
• 7 章. Northflank — マルチクラウド、シリアスなチームの PaaS
• 8 章. Heroku — 死んだという噂は誇張だった
• 9 章. Cloud Run — GCP の隠れチャンピオン
  • 9.1 Cloud Run に Next.js をデプロイ
• 10 章. AWS App Runner / ECS Fargate — AWS の出口
• 11 章. Coolify · Dokku — 「PaaS の価格が狂っている、自分でホストする」
• 12 章. コストマトリクス — $5k/月 SaaS の実際の請求書
• 13 章. コールドスタートの真実
• 14 章. 永続ディスクの黄昏と復活
• 15 章. バックグラウンドワーカーの現実
• 16 章. マルチリージョン — グローバル SaaS の現実
• 17 章. 意思決定フレーム — どの PaaS を選ぶべきか
• 18 章. アンチパターン集
• エピローグ — 道具ではなくワークロードを見よ
  • PaaS 選択チェックリスト
  • 次の記事予告
• 参考 / References

プロローグ — Heroku が去った席に誰が座ったのか

2022 年、Salesforce が Heroku の無料ティアを殺した。その日 Twitter では一世代のインディハッカーが同時に悲鳴を上げた。「Heroku が死んだ。これからどこにデプロイすればいいんだ」。その悲鳴から始まった 4 年の PaaS 黄金期が、2026 年春にようやく形を成した。

まず誤解を解いておく。Heroku は死んでいない。Salesforce が無料ティアを殺し、価格政策を一度整理しただけで、2026 年現在 Heroku は生きていて、Heroku-24 スタックと Postgres 17 までサポートしている。ただ「デフォルト」の席を失った。新規プロジェクトのデフォルトはもはや Heroku ではない。

その空席を狙う候補が多すぎる。Vercel は Next.js の事実上の本家となり、v0 と ai-sdk まで吸収して「フレームワークファースト PaaS」というカテゴリを作った。Render は「Heroku が恋しい? 俺たちが Heroku だ」をスローガンに永続ディスク、Cron、バックグラウンドワーカー、Postgres を一つにまとめた。Fly.io は Docker ファーストのグローバル PaaS でマルチリージョンを些細な事にした。Railway は分単位リソース課金と美しい UX で新世代を取り込んだ。Northflank はマルチクラウドと BYOC、より高度なプリミティブ — Job、Cron、Volume、Build Pipeline — でシリアスなチームの目を引いた。Netlify は Vercel の兄だが、弟に席を奪われた後 JS フレームワークホスティングに集中して生き残った。

クラウド勢が愛するダークホースもある。Cloud Run — GCP のサーバーレスコンテナ — は 100ms 単位課金とゼロまでのスケールダウンで一部のワークロードでは他のすべての PaaS を価格で粉砕する。AWS App Runner と ECS Fargate は AWS の出口を望むチームの選択。Coolify と Dokku は「PaaS の価格が狂っている、自分でホストする」勢の選択。

この記事はこれらの PaaS を同じ軸で正面比較する。比較の後、四つのシナリオ — Next.js アプリのデプロイ、API + Postgres + Redis + ワーカースタック、グローバルマルチリージョン SaaS、$5k/月 トラフィックのフルスタックアプリ — でどの道具を選ぶべきかを問う。価格は速く動く。すべての数字は 2026 年 5 月時点 で、構造の違いに焦点を置く。半年後に数字が変わっても、意思決定フレームは有効でなくてはならない。

同じカテゴリの PaaS でも、課金モデル と ランタイムモデル が違えば、ひと月の請求書は 10 倍まで開く。そして去るコストは入るコストの 10 倍である。

1 章. PaaS の定義 — 何が PaaS で何がそうでないか

2026 年に「PaaS」という単語を使うなら、まず境界線を引く必要がある。狭義の PaaS — Platform as a Service — は Heroku が定義した。git push heroku main の一行でコードがビルドされ、デプロイされ、ドメインが付く。インフラは見えない。データベース、キャッシュ、キューはアドオンとして一行で追加される。

この定義で Vercel · Netlify · Render · Fly.io · Railway · Northflank · Heroku · Coolify · Dokku はすべて PaaS だ。コードをプッシュすればデプロイされる。

境界線上の道具もある。Cloud Run はコンテナをプッシュすれば自動でスケーリングされるサーバーレスコンテナプラットフォームだ。狭義の PaaS よりも一段低い抽象 — Postgres もビルドパイプラインも別途付ける必要がある — だが、事実上 PaaS のように使われる。AWS App Runner も同じカテゴリ。ECS Fargate と Kubernetes は PaaS より一段低い CaaS — Container as a Service — または IaaS に近い。

この記事は狭義の PaaS と Cloud Run / App Runner までを扱う。ECS Fargate と EKS は比較表に少し登場するが本格的な比較対象ではない。

1.1 PaaS の五つの軸

同じ軸で比較しないと比較ではない。五つの軸を先に定義する。

• ビルドモデル — Buildpack? Dockerfile? フレームワーク自動検出? Nixpacks?
• ランタイムモデル — 常時起動? ゼロまでスケールダウン? リクエスト単位インスタンス?
• 永続性 — 永続ディスク? Postgres? Redis? Object Storage?
• 課金 — インスタンス時間? CPU 秒? リクエスト数? 帯域? 無料ティア?
• 運用 — ログ? メトリクス? シークレット? プレビュー環境? ロールバック? マルチリージョン?

各 PaaS をこの軸で一行要約すると以下のとおり。

表だけ見てもパターンが見える。Vercel · Netlify · Cloud Run は「ゼロまでスケールダウン、永続ディスクなし」 陣営、Render · Fly.io · Railway · Northflank · Heroku は「常時起動、永続ディスクあり」 陣営。この一行の差がすべての価格計算とワークロード適合度を決定する。

2 章. Vercel — Next.js の本家、そして v0 まで

Vercel は 2026 年現在最も騒がしい PaaS だ。Next.js の事実上の本家であり、ai-sdk の本家であり、v0 — UI を作ってくれる AI — の本家であり、AI Gateway という新カテゴリまで作った。

良い点。Next.js を使えば他のオプションを悩む必要がほとんどない。git push 一回でビルドされ、プレビュー環境が PR ごとに自動で生まれ、エッジに自動デプロイされ、画像最適化と分析が基本で付く。ソロ開発者の立場では「ただデプロイ」の定義が Vercel である。

問題。価格だ。2024 年末に Vercel は課金モデルを一度ひっくり返した。既存の「関数呼び出し数 · GB-Hr · 帯域」モデルから Active CPU モデルに変えた。Active CPU は CPU が実際に仕事をした時間だけ課金するもの — 外部 API レスポンス待ちや DB I/O 待ち時間は除外。理論上はより安い。

実際にはどうか。価格ページの数字 — Active CPU 時間 $0.128、Provisioned Memory $0.0106 per GB-Hr、Edge Requests 100 万件あたり $2 — だけ見れば合理的だ。しかしトラフィックが増えると請求書がすばやく膨らむ。特に Server Components で大きなページを描く Next.js アプリは、ページあたりの Active CPU 時間が長くなる。

$5k/月 売上の SaaS が Vercel でいくら使うか。コミュニティ報告 — Reddit r/nextjs、Twitter の SaaS ビルダーたち — を平均するとトラフィック 1–5 万 MAU 帯で月 $150–$600 の間が出る。それ以上は Pro の $20/席 ベースと使用量超過分が積み重なって急速に膨らむ。

Vercel の本当の落とし穴は 永続性がない 点だ。Postgres は Vercel Postgres — 実は Neon の OEM — で、Redis は Vercel KV — 実は Upstash の OEM — だ。これらは追加コストで、トラフィックに応じて別途請求書が膨らむ。Vercel 内ですべてを閉じて運用すれば結局 Neon と Upstash の直接価格より高くなる。

2.1 Vercel に Next.js + Postgres + Redis をデプロイ

最も簡単なワークフローはこう。

# 1. ローカルで Next.js アプリを作る
npx create-next-app@latest my-saas

# 2. Vercel に接続
cd my-saas
vercel link

# 3. Vercel Postgres (= Neon) と Vercel KV (= Upstash) を追加
vercel storage create postgres
vercel storage create kv

# 4. 環境変数の自動注入を確認
vercel env pull .env.local

# 5. プッシュすれば終わり
git push

vercel.json もほぼ必要ない。プレビュー環境、ドメイン、HTTPS、画像最適化は自動。バックグラウンドワーカーが必要? Vercel Cron または Vercel Queues — ベータ — を使うか、外部キュー — Inngest, Trigger.dev — を付ける必要がある。Vercel 内で「常時起動のワーカー」を回す方法はない。

2.2 Vercel の適合領域

Vercel は Next.js · React Router · SvelteKit · Astro のようにフレームワークビルドが定型化されているアプリに最適だ。SSG 中心のサイト — 会社ブログ、マーケティング、ドキュメント — も無料ティアで十分。AI インターフェース — チャット、コード補助、コンテンツ生成 — は ai-sdk と AI Gateway がワークフローを短くする。

逆に 常時起動の Express/Fastify サーバー、Postgres + Redis + ワーカーが同じ箱で回るモノリス、WebSocket が中心の実時間アプリ、gRPC のようなワークロードは Vercel に合わない。無理に押し込むことはできるが価格も運用も両方ダメ。

3 章. Netlify — Vercel の兄、生き残った兄

Netlify は Vercel より先に始まった。2014 年創業、「JAMstack」という単語を作った会社だ。Vercel が 2017 年に始まり Next.js を背負って追い越すまで、Netlify がその席にいた。

2026 年の Netlify は弟の席だ。Next.js の本家は Vercel に奪われ、価格モデルも似た方向に追従した。それでも Netlify が生き残った理由は二つある。

第一に、Next.js 以外のフレームワークに対してより中立だ。Astro、Remix、SvelteKit、Hugo、Eleventy、Gatsby — すべて Netlify でよく動く。Vercel も他のフレームワークをサポートするが「Next.js が一等市民、それ以外は二等」という空気がある。Netlify はその空気が薄い。

第二に、ビルド環境の安定性だ。Netlify のビルドシステムは古く、その分深い。大きなモノレポの SSG ビルドを安定して回すことに関しては Netlify が依然優位だという報告が多い。

価格は Vercel とほぼ平行だ。Free ティア — 100GB 帯域、ビルド分 300 — 、Pro $19/月/席。関数呼び出しと Edge Functions も似た単位で課金する。Netlify Blobs — Object Storage — と Netlify Forms — フォーム送信処理 — は Vercel にない小さな差別点。

問題は同じだ。永続ディスクがなく、ワーカーが弱く、Postgres と Redis は別だ。Netlify Postgres は 2026 年ベータにあるが、Neon の OEM である点で Vercel Postgres と同じ位置。

いつ Netlify を選ぶか。Next.js でないフレームワークの SSG/SSR サイト、モノレポ SSG、すでに Netlify でよく動いているサイトの移行コストが負担になる場合。新しい Next.js プロジェクトなら、わざわざ Netlify を選ぶ理由はない。

4 章. Render — 「Heroku が恋しい? 俺たちが Heroku だ」

Render は 2019 年に登場した PaaS だ。最初から「Heroku の後継」を明示的に標榜した。2022 年の Heroku 無料ティア死亡以後、最大の受益者が Render だった。

Render のスローガンが効く理由。Heroku が得意だったこと — Postgres、Redis、バックグラウンドワーカー、Cron、永続ディスク、シンプルな価格 — を Render がすべて一つの場所で提供する。render.yaml 一ファイルに Web サービス + ワーカー + Cron + Postgres + Redis を宣言すればそのまま回る。

2026 年の価格モデルはシンプルだ。Web Service · Background Worker · Private Service はインスタンス時間課金。Starter $7/月、Standard $25/月、Pro $85/月 程度が基本ライン。Postgres は Starter $7/月 (256MB RAM, 1GB storage)、Standard $20/月 から始まる。Redis も似たライン。Persistent Disk は GB あたり月 $0.25。Cron Job は無料 — 実行時間のみ課金。

$5k/月 SaaS の Render 請求書を推定すると、Web Service 一台 ($25) + Worker 一台 ($25) + Postgres Standard ($20) + Redis Starter ($10) + ディスク 10GB ($2.5) = 月 $82.5。同じワークロードを Vercel + Neon + Upstash で組むと $150–$300 の間が一般的。Render が単純により安い。

Render の落とし穴。第一に、コールドスタートではなく 「スリープ」がある — Free ティアに限り。無料インスタンスは 15 分非活性で眠り、次のリクエストで 20–30 秒程度起きる時間がかかる。有料ティアは常時起動。第二に、グローバルマルチリージョンデプロイは弱い。Render はリージョン — Oregon、Ohio、Virginia、Frankfurt、Singapore — を選ぶが、一つのサービスを複数リージョンに同時に立てるのは比較的最近の機能で、Fly.io ほど滑らかではない。

4.1 Render に Next.js + Postgres + Redis + Worker をデプロイ

# render.yaml
services:
  - type: web
    name: app
    runtime: node
    buildCommand: pnpm install && pnpm build
    startCommand: pnpm start
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: app-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          type: redis
          name: app-redis
          property: connectionString
  - type: worker
    name: worker
    runtime: node
    buildCommand: pnpm install && pnpm build:worker
    startCommand: pnpm start:worker
  - type: redis
    name: app-redis
    ipAllowList: []
    plan: starter

databases:
  - name: app-db
    plan: starter
    region: oregon

このファイルをプッシュすれば終わりだ。Vercel のミニマリズムと Heroku のフルスタックを合わせた感覚。

5 章. Fly.io — Docker ファースト、グローバルファースト

Fly.io は他の PaaS と出発が違う。最初から Docker と マルチリージョン が一等市民だった。2026 年現在 Fly.io のユーザー体験は大きく二度ひっくり返された — 一度目は Nomad ベースの Apps v1、二度目は Firecracker MicroVM ベースの Machines / Apps v2。

Fly Machines の本質。Fly Machine は Firecracker MicroVM 一つだ — KVM の軽量仮想マシン、AWS Lambda が使っているのと同じ技術。起動時間は 250ms 水準、停止・再開 — fly machine stop / start — が可能で、一つのアプリが複数リージョンに複数の Machine を持てる。価格は Machine の CPU/メモリ時間で課金されるが、停止状態ではほぼ無料 (ストレージ費用のみ)。

Fly Postgres と Volumes。Postgres は Fly が直接運営するのではなく — 正確には 2024 年にマネージド運営を終了して — Supabase Postgres on Fly か直接 Postgres MicroVM を立てるモデルに行った。Volume — 永続ディスク — は生きていて、Machine に直接マウントする。

fly.toml 一ファイルで十分だ。

# fly.toml
app = "my-saas"
primary_region = "nrt"

[build]
  dockerfile = "Dockerfile"

[env]
  PORT = "8080"

[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 1

  [[services.ports]]
    handlers = ["http"]
    port = 80

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

[mounts]
  source = "data"
  destination = "/app/data"

fly deploy 一回で終わり。マルチリージョンが欲しい? fly scale count 1 --region nrt,sin,fra のようなコマンド一行。

Fly の価格。最も小さい Machine — shared-cpu-1x · 256MB — は月 $2 以下。一般的なワークロード — shared-cpu-2x · 1GB — は月 $5–$10 程度。帯域は北米・欧州で GB あたり $0.02。$5k/月 SaaS の Fly 請求書は Render と似ているか少し安く出るケースが多い — ただし運用自動化 — Postgres バックアップ、Redis HA — を自分でより多くやる必要がある。

Fly の落とし穴。第一に、運用負担が大きい。Render が自動でやってくれること — Postgres バックアップ、モニタリング、アラーム — を Fly では自分で書く。第二に、ローカルデバッグが難しい。Firecracker MicroVM の特性上 SSH ではなく fly ssh console で入り、誤って永続ディスクを飛ばすと回復が難しい。

5.1 Fly の真の強み — マルチリージョンが些細

他の PaaS で一つのアプリを東京、シンガポール、フランクフルトの三リージョンに同時に立てるのは仕事だ — Render は最近になって、Vercel はエッジのみで、Cloud Run はリージョンごとに別途デプロイ。Fly では一行。グローバル SaaS のレイテンシーを 50ms 以下に抑えたいなら、Fly が最も少ない摩擦でそれをやる。

6 章. Railway — 分単位リソース、美しい UX

Railway は 2020 年に始まった。最初から「Heroku が恋しい? 俺たちもだ」陣営で、2026 年現在最も美しい UX を持つ PaaS だ。ダッシュボードを見るだけで他の PaaS との差を感じる。

Railway の差別点。第一に、リソース単位の分単位課金。Vercel の Active CPU と類似するが、Railway は Web サービスにも同様に適用される。CPU 分あたり $0.000463、メモリ GB 分あたり $0.000231 程度。一つのサービスがアイドル状態 — トラフィックなし — のとき課金がほぼ 0 に落ちる。ただし Railway は完全に 0 までスケールダウンはしない — インスタンスは生きている。

第二に、Hobby Plan vs Pro Plan。Hobby は $5/月 ベース — $5 分のリソースクレジットが含まれる。Pro は $20/月 ベース + チーム協業 + より大きなインスタンス。ソロ開発者は Hobby で始めて十分な場合が多い。

第三に、Postgres、Redis、MySQL、MongoDB が一度のクリック。データベースインスタンスもリソース単位課金で、小さい DB は月 $3–$5 水準。

$5k/月 SaaS の Railway 請求書。トラフィックパターンによるが、軽い SaaS — Web + Worker + Postgres + Redis — は月 $30–$80 の間が多い。重い SaaS — 大きな Postgres、常時起動のワーカー — は $150–$300。Render と似ているか少し安い。

Railway の落とし穴。第一に、分単位課金は重いワークロードで高くなる。常時起動の大きなインスタンスを回すと、Render のフラットなインスタンス時間課金のほうが予測しやすい。第二に、バックアップとマルチリージョンが弱い — Render よりも。第三に、Free ティアが事実上ない — $5 ベースが参入障壁。

6.1 Railway の魅力 — コードなしインフラ

Railway の真の魅力はダッシュボードだ。Postgres 追加、Redis 追加、環境変数共有、プライベートネットワーク、ドメイン — すべてクリック数回。render.yaml や fly.toml のような設定ファイルを書く必要がない。これがソロ開発者にとって大きな差になる。

# Railway CLI だけでも可能
npm i -g @railway/cli
railway login
railway init my-saas
railway add postgresql
railway add redis
railway up

7 章. Northflank — マルチクラウド、シリアスなチームの PaaS

Northflank は 2020 年にロンドンで始まった。他の PaaS より一段上の抽象を狙った。一言で 「PaaS だが Kubernetes 並みに強力」。

Northflank の差別点。第一に、マルチクラウド / BYOC。自分の AWS · GCP · Azure アカウントに Northflank を立てられる。データ主権が重要、または既存のクラウドクレジットを使いたいチームの選択。第二に、Job と Cron の一等支援。Render の Cron より豊富なスケジューラ。第三に、Build Pipeline。Docker ビルドを Northflank 内で実行し、結果物を他の Northflank サービスに自動デプロイ。

価格は Render と似たライン。小さいインスタンス $5–$10/月、標準 $25–$50/月。Postgres · Redis · MySQL · MongoDB もマネージドで提供される。

Northflank の落とし穴。第一に、ラーニングカーブが PaaS の中で最も高い。UI が強力な分複雑だ。第二に、コミュニティが小さい — Render、Fly、Railway よりユーザーが少なく検索で出てくる答えが少ない。第三に、ソロ開発者の最初の選択としては過剰 — 通常はシリアスなチームの二つ目の PaaS。

いつ Northflank を選ぶか。自分のクラウドアカウントにデプロイしたいとき、データ主権 — GDPR、韓国個人情報保護法、医療/金融規制 — のために位置を統制したいとき、Kubernetes までは行かずに PaaS より多くの統制が必要なとき。

8 章. Heroku — 死んだという噂は誇張だった

Heroku は 2007 年に始まり、2010 年に Salesforce に買収され、2022 年に無料ティアを殺して多くの敵を作った。しかし死んではいない。2026 年現在 Heroku は生きていて、Heroku-24 スタック (Ubuntu 24.04 LTS ベース)、Postgres 17、PCI · HIPAA コンプライアンス、Salesforce 統合 まで備えたエンタープライズ PaaS だ。

Heroku が生きている理由。第一に、すでに Heroku でうまく回っているアプリが多すぎる。大企業が Heroku に 5–10 年運用したモノリスを離れるコストは留まるコストの 10 倍。第二に、Salesforce エコシステムとの統合。SFDC と Heroku Connect で双方向同期するワークフローは Heroku だけが可能。第三に、Eco · Basic Dyno が無料ティアの席を一部復元した — Eco Dyno $5/月 で 1,000 時間、スリープ可。Basic Dyno $7/月 常時起動。

価格。Eco $5、Basic $7、Standard-1X $25、Standard-2X $50、Performance-M $250。Postgres は Mini $5、Basic $9、Standard-0 $50、Standard-2 $200 ... 。Redis は Mini $3、Premium $15 から。同じワークロードを Render · Railway · Fly で組むと通常 20–40% 安い。

Heroku を新規で選ぶ理由。一つだけ — Salesforce との統合。それ以外、新規プロジェクトがわざわざ Heroku を選ぶ理由は弱い。

9 章. Cloud Run — GCP の隠れチャンピオン

Cloud Run は PaaS 比較記事でよく抜ける。理由は単純だ — GCP コンソールの UX が他の PaaS より複雑で、GCP の無料クレジットを使い切った人だけが本気で請求書を見る。しかし請求書を見た人の多くが Cloud Run のファンになる。

Cloud Run の本質。コンテナをプッシュすれば リクエスト単位 のインスタンスで自動スケーリングされる。リクエストがなければ 0 に落ちる。リクエストが入ると 100ms 以内に起きる。インスタンスが一度に同時処理できるリクエスト数 — concurrency — を自分で決められ、デフォルトは 80。

価格が狂っている理由。100ms 単位課金 + ゼロまでスケールダウン + 毎月最初の 240,000 vCPU 秒と 450,000 GiB 秒が無料。小さい SaaS — $5k/月 売上、トラフィック日 1–5 万 — の Cloud Run 請求書はしばしば月 $5–$50 水準。同じワークロードの Vercel 請求書は $150–$600、Render は $80–$150。

Cloud Run の落とし穴。第一に、GCP の他のサービスを一緒に使う必要がある。Cloud SQL — Postgres — は別途請求、Cloud Memorystore — Redis — は高い、Cloud Storage — Object — は別途。GCP 内ですべて閉じれば結局他の PaaS と似た価格になることがある。第二に、リクエスト単位インスタンスモデルは WebSocket · gRPC streaming に不適 — Cloud Run 2 世代が一部サポートするが制約あり。第三に、コールドスタートがゼロではない — 最初のリクエストは 100ms–数秒 (イメージサイズと依存に依存)。

9.1 Cloud Run に Next.js をデプロイ

# 1. Dockerfile 作成
# (Next.js 公式 Dockerfile 例を使う)

# 2. Cloud Build + Cloud Run 同時デプロイ
gcloud run deploy my-saas \
  --source . \
  --region asia-northeast1 \
  --allow-unauthenticated \
  --memory 512Mi \
  --cpu 1 \
  --concurrency 80 \
  --min-instances 0 \
  --max-instances 100

# 3. Cloud SQL Postgres 接続
gcloud run services update my-saas \
  --add-cloudsql-instances PROJECT:REGION:INSTANCE \
  --set-env-vars DATABASE_URL=postgres://...

--min-instances 1 にすればコールドスタートが消えるが、常時起動インスタンス一台の時間課金が入る。それでも他の PaaS の常時起動インスタンスよりは通常安い。

10 章. AWS App Runner / ECS Fargate — AWS の出口

すでに AWS の中にすべてがあるチームなら、他の PaaS を追加導入するコストが負担になる。そのチームの PaaS 出口が App Runner と ECS Fargate だ。

App Runner。コンテナまたは GitHub リポジトリをプッシュすると自動ビルド · デプロイ。Cloud Run と似ているが 常時起動 モデル — 0 までスケールダウンしない。価格は vCPU 分あたり $0.064、メモリ GB 分あたり $0.007 程度。$5k/月 SaaS の App Runner 請求書は通常 $80–$200。

App Runner の位置。AWS コンソール内で他の AWS サービス — RDS、ElastiCache、S3、SQS — と滑らかに統合される。AWS が一等市民のチームでは価値がある。しかし AWS 外の PaaS — Render、Railway、Fly — が同じワークロードをより安く簡単にやる。

ECS Fargate。Container as a Service。ECS の Task Definition を定義し Fargate で立てる。PaaS より一段低い抽象 — VPC、ALB、IAM、Task Role を自分で書く必要がある。しかし統制権はその分大きい。大きいチームのメインワークロードは ECS Fargate または EKS にあることが多く、App Runner と PaaS は補助ワークロード用。

価格比較。同じ 1 vCPU + 2GB メモリを 1 ヶ月常時起動で回すと、ECS Fargate は約 $36/月、App Runner は約 $40–$50/月。Render の Standard が $25/月、Fly の dedicated-cpu-1x が $30/月。AWS が少し高いが、他の AWS サービスとの統合価値がその差を埋められる。

11 章. Coolify · Dokku — 「PaaS の価格が狂っている、自分でホストする」

PaaS の価格が気に障る人達はいつもいる。「Hetzner VPS が月 $5 で 4 vCPU + 8GB メモリをくれるのに、Render で同じ仕様が $85 なのは話にならない」。そういう人達の道具が Coolify と Dokku だ。

Coolify。2022 年に登場し 2025 年頃に爆発的に成長したオープンソースのセルフホスト PaaS。自分の VPS — Hetzner、DigitalOcean、OVH — に Coolify をインストールすると、その上で Heroku のような体験が可能。GitHub 連動、自動デプロイ、ドメイン、HTTPS — Let's Encrypt 自動 — 、Postgres · Redis · MySQL · MongoDB マネージド、モニタリングまで。

Coolify の本当の価格。Coolify 自体は無料だ (Pro $5/月 はクラウドホストされた Coolify インスタンスの価格)。VPS 費用 — Hetzner CX31 (2 vCPU, 8GB) が月 $13 — だけかかる。一つの VPS に 10 個のアプリを回せばアプリあたり月 $1.3。Render の 1/20 価格。

Coolify の落とし穴。第一に、自分で運用する必要がある。OS アップデート、セキュリティパッチ、バックアップ、モニタリング — すべて自分の仕事。第二に、HA が弱い。単一 VPS にすべてがあれば、その VPS が死ぬときすべてのアプリが死ぬ。Coolify のクラスター機能 — マルチノード — はベータ。第三に、ラーニングカーブが意外にある。PaaS のシンプルさを期待すると最初の 2 週間が苦しい。

Dokku。2013 年から生きているオープンソースのミニ Heroku。Coolify よりシンプルで、GUI がなく (コミュニティ GUI はある)、CLI だけで動く。dokku apps:create my-app、git push dokku main — Heroku の CLI とほぼ同じ。ソロ開発者が自分の VPS に Dokku を入れて 5 個の小さなアプリを回すのは、2026 年でも合理的な選択。

いつ Coolify / Dokku を選ぶか。お金を節約したく、運用を学びたく、HA が絶対ではないサイドプロジェクト。本業 SaaS には通常不適 — 一度ダウンするとビジネスインパクトが VPS 費用節約を圧倒する。

12 章. コストマトリクス — $5k/月 SaaS の実際の請求書

以下は同じワークロード — Next.js 14 アプリ + Postgres (10GB、軽いワークロード) + Redis (256MB) + バックグラウンドワーカー一台 — を各 PaaS にデプロイしたときの推定月請求書だ。トラフィックは月 100 万ページビュー、日平均 3 万リクエストを仮定。

解釈。価格だけ見れば Coolify · Dokku が圧倒的に安い。しかしそれは自分が運用するコスト — 時間 + リスク — を除いて見た数値だ。マネージド PaaS の $80 は高いのではなく保険料だ。マネージド PaaS の中では Railway と Fly.io が最も安く、Render がその次、Vercel · Heroku · App Runner が最も高い。

価格は一つの軸に過ぎない。他の軸 — 運用のシンプルさ、ワークロード適合度、移行コスト、チーム合意 — を一緒に見ないと決定が間違う。

13 章. コールドスタートの真実

「コールドスタート」という単語は 2026 年でも PaaS 論争の中心にある。真実はこうだ。

ゼロまでスケールダウンするプラットフォームだけにコールドスタートがある。常時起動の PaaS — Render、Railway、Heroku、Northflank — にはコールドスタートがない。ただインスタンスが死んで再起動するときの時間はあるが、これはコールドスタートより短い。

Vercel · Netlify · Cloud Run · Fly Machines (auto_stop) はコールドスタートがある。一般的なコールドスタート時間:

• Vercel Functions — Node.js 小さい関数 100–500ms、大きい SSR 1–3 秒
• Netlify Functions — 似たライン
• Cloud Run — 100ms–2 秒、イメージサイズに大きな影響
• Fly Machines (auto_stop) — 250–500ms、Firecracker の強み
• AWS Lambda — Node 100–500ms、Java/Python はもっと長い

コールドスタートが問題になるワークロード。リアルタイムチャット、ゲーム、トレーディング、決済処理。ユーザーが最初のリクエストで 2 秒待つことが事業的に損失になる場合。

解決法三つ。(1) Min instances 1 以上 — Cloud Run と Fly Machines 両方サポート。常時起動のインスタンスを 1 台置いて最初のリクエストを受ける。(2) Provisioned Concurrency — AWS Lambda の機能。(3) 常時起動の PaaS に移る。

14 章. 永続ディスクの黄昏と復活

2018–2022 年の間 PaaS の大きなトレンドは「永続ディスクはアンチパターン」だった。すべての状態は外部 — Postgres、Redis、S3 — に送り、コンピュートは stateless に保つのが模範。Vercel · Netlify がその方向を極端に押した。

2023–2026 年のトレンドは一部巻き戻った。永続ディスクが必要なワークロードがまた見えた。

• SQLite + Litestream — SaaS の最もシンプルなデータ層。一つの VM の中に SQLite とアプリが一緒に住み、Litestream が S3 に非同期バックアップ。Fly.io と Render はこのパターンをよくサポートする。
• セルフホスト ベクトル DB — pgvector、Qdrant、Weaviate を自分のインスタンスに立てるとき永続ディスクが必要。
• ファイル処理ワークフロー — 画像変換、ビデオトランスコード、大きいファイルの一時保存。
• ローカルキャッシュ — Redis を使わない場合のディスクキャッシュ。

永続ディスクが必要か? Render、Fly.io、Railway、Northflank、Coolify · Dokku を見る。Vercel、Netlify、Cloud Run、App Runner は候補から外れる。

15 章. バックグラウンドワーカーの現実

「バックグラウンドワーカー」は SaaS の隠れた半分だ。メール送信、決済 webhook 処理、ビデオ変換、レポート生成、定期データ同期 — すべてワーカーがやる。PaaS のワーカーサポートレベルは大きく分かれる。

一等支援 — Render、Railway、Fly.io、Northflank、Heroku、Coolify。ワーカー = 常時起動のプロセス。worker.js を起動してキューをポーリングするかメッセージを受け取ればいい。

部分支援 — Cloud Run Jobs、App Runner。Cloud Run Jobs は実行可能なワーカーだが常時起動のワーカーではない — 呼ばれれば実行されて終わる。キューポーリングワーカーは Cloud Run ではぎこちない。

弱い — Vercel、Netlify。Vercel Queues がベータにあるが、常時起動のワーカーモデルはない。外部ワーカーインフラ — Inngest、Trigger.dev、Defer、Hatchet — を付けるのが一般的な解。これが Vercel の本当のコスト増加要因。

ワーカーが重い SaaS — 画像/ビデオ処理、AI 推論、ETL — なら Vercel より Render · Fly · Railway がほぼ常により適している。

16 章. マルチリージョン — グローバル SaaS の現実

グローバルユーザーを持つ SaaS のレイテンシーを 50ms 以下に抑えたいならマルチリージョンが必要。マルチリージョンサポートの現実はこうだ。

最も滑らか — Fly.io。fly scale count 1 --region nrt,sin,fra,iad 一行。マルチリージョン Postgres も Fly が一時うまくやっていた (現在は Supabase と協力モデル)。

自動エッジ — Vercel、Netlify。Edge Functions と静的アセットは世界中のエッジに自動デプロイ。しかしデータベースはエッジにない — Neon、PlanetScale、Supabase 等がマルチリージョン読み取りレプリカを提供。

リージョン選択可能 — Render、Railway、Northflank、Heroku。一つのサービスを一つのリージョンにデプロイするが、同じサービスを複数リージョンに同時デプロイは比較的最近の機能かベータ。グローバル SaaS の最初の候補ではない。

自動グローバル — Cloud Run。--region を複数指定すれば複数リージョンに同じサービスを立てられる。ただし Load Balancer と Cloud Run multi-region 設定を自分で書く必要がある。

グローバルマルチリージョンが必須なら Fly.io が最も少ない摩擦、Cloud Run がその次、Vercel + グローバル DB がその次。

17 章. 意思決定フレーム — どの PaaS を選ぶべきか

PaaS 選択のシンプルな意思決定木はこう。

開始点: どんなアプリか?

1. Next.js · React Router · SvelteKit 中心の SSG/SSR + 軽い API → Vercel (または Netlify)。他のオプションは価格が似ているかより高く、Vercel の統合価値が大きい。
2. モノリス — Web + ワーカー + DB + Redis が一つの箱で回るアプリ → Render (または Railway)。Heroku のような体験を最もよく提供する。
3. グローバルユーザー、マルチリージョン必須 → Fly.io。最も少ない摩擦。
4. AWS の中にすべてがあるチーム → App Runner または ECS Fargate。AWS の出口。
5. 自分のクラウド / データ主権 → Northflank。
6. お金を極端に節約して運用学習に時間があるソロ → Coolify on Hetzner または Dokku。
7. すでに GCP → Cloud Run + Cloud SQL。
8. Salesforce 統合 → Heroku。

チーム規模で見ると:

• ソロ / サイドプロジェクト — Vercel (Hobby) · Fly · Railway · Coolify
• 2–5 人の小さなチーム — Vercel Pro · Render · Railway · Fly
• 5–20 人のシリアスな SaaS — Render · Railway · Northflank · Fly
• 20+ 人 / コンプライアンス必要 — Northflank · Heroku · App Runner · Cloud Run

ラーニングカーブで見ると (短い順):

Vercel > Railway > Render > Heroku > Netlify > Fly > Cloud Run > Coolify > Northflank > App Runner > ECS Fargate。

18 章. アンチパターン集

PaaS 選択を台無しにする頻出パターンをまとめる。

1. 価格だけ見て決定。Coolify on VPS が $13/月 だからと本業 SaaS をそこに上げて、一度のダウンでビジネスが止まる。マネージド PaaS の $80 は高いのではなく保険料だ。

2. 「Vercel がすべてをやる」想定。Next.js だけが得意で、すべてのワークロードが得意なわけではない。常時起動のワーカー、大きいモノリス、WebSocket 中心のアプリは Vercel の外がいい。

3. PaaS 内のマネージド DB 使用で開始。Vercel Postgres、Render Postgres、Railway Postgres は始めやすいが移行コストが大きい。最初から Neon / Supabase / PlanetScale のような独立マネージド DB を使えば PaaS だけ差し替えられる。

4. マルチリージョンを早すぎて導入。ユーザーが一つの大陸にいるのにマルチリージョンをわざわざやる。単一リージョン + CDN で十分な場合が多い。

5. Free ティアを本業に使用。Free のコールドスタート、スリープ、小さいリソースがユーザー体験を台無しにする。本業は有料ティアで始める。

6. コールドスタート無視。Vercel · Cloud Run のコールドスタートを知らずに入って、最初のリクエスト 1–3 秒でユーザーが去る。min instances 1 以上 または常時起動の PaaS に移る。

7. バックアップとモニタリングを PaaS が全部やってくれると想定。Render · Railway の自動バックアップは一定保持期間だけ保証する。自分で追加バックアップを持っていかなければ事故時に復旧できない。

8. 「PaaS の価格が狂っている」と Kubernetes に移行。PaaS の月 $200 が狂っていると EKS に行くと EKS の $73/月 コントロールプレーン + ノード費用 + 運用時間 (= 週 5 時間) で結局より高くなる。PaaS 価格が気に障るならまず同じ PaaS カテゴリ内でより安い場所 — Railway、Fly — に移ることを試す。

エピローグ — 道具ではなくワークロードを見よ

PaaS 比較記事の落とし穴は道具中心の思考だ。「Vercel vs Render」ではなく「自分のワークロードに何が合うか」が問いだ。同じ SaaS でもユーザー分布、トラフィックパターン、ワーカー負担、データサイズ、コンプライアンス要件が違えば答えが違う。

2026 年の風景を一行で要約すると: Next.js = Vercel、モノリス = Render、グローバル = Fly、分単位課金 = Railway、シリアスマルチクラウド = Northflank、GCP = Cloud Run、AWS = App Runner、セルフホスト = Coolify。この 8 つを知っていれば新規プロジェクトの PaaS 決定はほぼ常に 5 分以内に終わる。

PaaS 選択チェックリスト

• 自分のアプリは 0 までスケールダウン可能なワークロードか? (コールドスタート許容?)
• 永続ディスクが必要か?
• 常時起動のワーカーが必要か? ワーカーが重いか?
• グローバルユーザーがいるか? 50ms 以下のレイテンシーが必須か?
• マネージド Postgres / Redis を PaaS 内で受けるか、外部 (Neon / Supabase / Upstash) に分離するか?
• コンプライアンス — HIPAA、PCI、GDPR、データ主権 — が必要か?
• チーム規模と運用可用時間はどれくらいか?
• 去るコスト — 他の PaaS への移行 — を事前に計算したか?
• 請求書はトラフィック 10 倍増のときどう変わるか?
• プレビュー環境、ロールバック、バックアップ、ログが十分か?

次の記事予告

次の記事では PaaS の上に乗る マネージドデータベース — Neon · Supabase · PlanetScale · Turso · Cloudflare D1 · CockroachDB Serverless を同じ深さで比較する。PaaS 決定の半分は DB 決定だ — それを分けて見れば PaaS 決定がより自由になる。

参考 / References

• Vercel 価格 — https://vercel.com/pricing
• Vercel Active CPU モデル — https://vercel.com/docs/pricing/billing
• Vercel AI SDK — https://sdk.vercel.ai
• Netlify 価格 — https://www.netlify.com/pricing
• Render 価格 — https://render.com/pricing
• Render ドキュメント — https://render.com/docs
• Fly.io 価格 — https://fly.io/docs/about/pricing
• Fly Machines — https://fly.io/docs/machines
• Fly Apps v2 — https://fly.io/docs/apps
• Railway 価格 — https://railway.com/pricing
• Railway Hobby vs Pro — https://docs.railway.app/reference/pricing
• Northflank 価格 — https://northflank.com/pricing
• Northflank BYOC — https://northflank.com/docs/byoc
• Heroku 価格 — https://www.heroku.com/pricing
• Heroku-24 スタック — https://devcenter.heroku.com/articles/heroku-24-stack
• Cloud Run 価格 — https://cloud.google.com/run/pricing
• Cloud Run ドキュメント — https://cloud.google.com/run/docs
• AWS App Runner — https://aws.amazon.com/apprunner
• AWS Fargate 価格 — https://aws.amazon.com/fargate/pricing
• Coolify — https://coolify.io
• Coolify ドキュメント — https://coolify.io/docs
• Dokku — https://dokku.com
• Neon — https://neon.tech
• Supabase — https://supabase.com
• Upstash — https://upstash.com
• Inngest (Vercel ワーカー補完) — https://www.inngest.com
• Trigger.dev — https://trigger.dev
• Heroku 無料ティア終了アナウンス (2022) — https://blog.heroku.com/next-chapter