DevOps PaaSプラットフォーム 2026 — Vercel / Fly.io / Render / Railway / Coolify / Dokploy / Kamal 徹底比較

プロローグ — Herokuが去った跡に14のPaaSが育った

2007年、Herokuが「git pushでデプロイ」を披露したとき、それは魔法のように見えた。git push heroku main の一行がRailsアプリをインターネットへ送り、それがPaaSの定義となった。

そして2022年11月、Salesforce傘下のHerokuが無料枠を廃止した。この出来事が2026年のPaaS風景を作った。サイドプロジェクトを失った開発者たちが四方に散り、その跡地に14のPaaSが育った。

2026年5月現在の風景はこうだ:

• Vercel はNext.jsの家となり、Fluid Computeでサーバーレスの弱点を埋めた。
• Fly.io はベアメタルに近いコンテナをマルチリージョンに展開する。
• Render は最も直接的なHerokuの代替だ。
• Railway は使いやすさで愛され、2024年にシリーズBを再調達した。
• Cloudflare はPages・Workers・R2でフルスタックエッジを完成させた。
• Netlify はJAMstackの先駆者からコンポーザブルなフルスタックプラットフォームへ変身した。
• Coolify はOSSセルフホスティングPaaSの事実上の標準となり、2024年にシード調達した。
• Dokploy はCoolifyに挑む。
• Kamal 2(37signals)は「自分のサーバーへのデプロイ」という古き美徳を蘇らせた。
• Heroku は2025年のIBM買収検討報道の後も生き残っている。
• Northflank はKubernetesの力をPaaSのUXで包んだ。
• Sevalla はKinsta製の新しいPaaSだ。
• Caprover・Easypanel はDocker優先のセルフホスティングを守る。

本稿は14のプラットフォームを一気に比較する。誰が何を選ぶべきかまで答える。

1章 · 2026年のPaaS地図 — マネージド / OSSセルフホスティング / VPS上の自前PaaSという三軸

PaaSを一行で定義するなら「コードをgit pushすればインターネットで動く」だ。だが2026年のPaaSはその一行の裏で三つに分かれる。

1.1 三つの軸

軸1 — マネージドクラウドPaaS。 Vercel・Fly・Render・Railway・Cloudflare・Netlify・Heroku・Northflank・Sevalla。カードを登録すれば心配ごとは消える。インフラが見えなくなる。代わりに月の使用量が請求書として戻ってくる。

軸2 — OSSセルフホスティングPaaS。 Coolify・Dokploy・Caprover・Easypanel。VPS一台(Hetzner・DigitalOcean・OVH・Vultr)にインストールすれば、その上でVercelに似た体験が回る。インフラコストはVPS料金だけ。バックアップ・監視・セキュリティパッチは自分の責任。

軸3 — VPS上の自前PaaS / 軽量コンテナオーケストレーター。 Kamal 2。PaaSではなく「自分が選んだサーバーへコンテナを綺麗にデプロイする道具」だ。37signalsがDHHの手で作り、Rails 7.2からはデフォルトのデプロイツールだ。

1.2 コスト対コントロールのマトリクス

                 コントロール ↑
                    |
    Kamal 2 ────────|──────── Coolify / Dokploy
    (VPSを直接運用)  |        (OSSセルフホスティング)
                    |
    ────────────────+────────────────  コスト →
                    |
    Heroku / Render |        Vercel / Cloudflare
    (古典的PaaS)    |        (エッジ・サーバーレス)
                    |
                 コントロール ↓

横軸は月のコスト、縦軸はインフラ管理権限。左上は安いが全部自分でやる。右下はカード一枚で全てが回る。

2022年のHeroku無料廃止以降、サイドプロジェクトの重心は左上に移った。 月5ドルのHetzner VPSにCoolifyを入れれば、5つのプロジェクトを一度に回せる。これが2026年の新しいデフォルトだ。

1.3 Gitドリブンデプロイ — みんなが共有する標準

三軸の全プラットフォームが共有する一つがある。Git pushがデプロイそのものだ。

• main ブランチへpushすれば本番が更新される。
• PRを開けばプレビューURLが自動生成される。
• PRを閉じればプレビューが消える。

Vercelが2017年に標準化したこの流れが、2026年にはセルフホスティングPaaSのデフォルトまで降りてきた。Coolify・Dokploy・CaproverはどれもGitHub Webhookをサポートし、プレビュー環境機能を備える。

2章 · Vercel — Next.jsの家、Fluid Computeの発明者

2026年のVercelは二つを同時にやる。Next.jsの家であり、Fluid Computeでサーバーレスのパラダイムを再定義した。

2.1 Fluid Compute — コールドスタートを終わらせたモデル

2024年8月にVercelが発表した Fluid Compute は一言でいうと「一つのインスタンスが複数のリクエストを同時に処理する」だ。

従来のAWS Lambda / Vercel Functionsモデルは:

• リクエスト1個 → インスタンス1個
• 同時リクエスト100個 → インスタンス100個
• 各インスタンスでコールドスタートの可能性

Fluid Computeモデルは:

• インスタンス1個が同時リクエストN個を処理
• AIの応答待ち中に他のリクエストへCPUを譲る
• コールドスタートが起きてもそのコストがN個のリクエストに分散

特に AI/LLMバックエンド で輝く。ChatGPT/Anthropic APIを呼びながら90%の時間をネットワーク待ちに使うなら、その待ち時間を他のリクエストが使う。同じトラフィックを処理するコストがおよそ1/3になる、というのがVercelの主張で、実測でも似た値が出る。

2.2 Vercelの強み

• Next.js 1:1統合。 App Router・React Server Components・Server Actions・Streaming・PPR(Partial Prerendering)が最も早く、最もよく動く。
• Preview Deployments。 PRごとに固有URL。クライアントがPRのコメントでフィードバックを残す流れが標準になった。
• Edge Network。 100以上のPOP。静的アセットが近くから配信される。
• Vercel KV / Postgres / Blob。 Upstash・Neon・R2の上に作ったマネージドデータ層。
• AI SDK。 TypeScriptでLLMを扱う最も整ったライブラリ。

2.3 Vercelの弱み

• 価格。 トラフィックが増えると素早く高くなる。特に画像最適化・Edge Middlewareリクエスト数が多い場合。
• ベンダーロックイン。 Next.js自体はOSSだが、ISR・Image Optimization・Edge ConfigはVercelの外で同じものを再現するのが難しい。
• 長時間実行バックエンドに不向き。 Fluid Computeでも単一リクエストの最大時間制限がある(Proで60〜300秒)。WebSocket・gRPCストリーミングサーバーには不向き。

2.4 誰が選ぶべきか

• Next.jsで作るSaaS、マーケティングサイト、ダッシュボード。
• AIチャットボット・検索などLLMバックエンドを持つNext.jsアプリ。
• クライアントとPR単位で協業するエージェンシー。

避けるべき場合: 24時間動くデーモン、5GBの機械学習モデルのサービング、コスト上限が明確なサイドプロジェクト。

3章 · Fly.io — マルチリージョン+ベアメタル親和

Fly.ioの一行要約は「あなたのDockerイメージを30都市に同時起動する」だ。Vercel・Renderと決定的に違うのは Fly Machines — Firecracker microVMベースのコンテナが実際の物理サーバーの近くで走る、という点だ。

3.1 マルチリージョンモデル

Flyにアプリをデプロイすると、fly.toml にリージョンリストを書く。

app = "my-app"
primary_region = "nrt"

[build]
  image = "ghcr.io/me/app:latest"

[[regions]]
  code = "nrt"
[[regions]]
  code = "iad"
[[regions]]
  code = "fra"

この一度の設定で東京・バージニア・フランクフルトに同時にインスタンスが立つ。トラフィックは最寄りのリージョンへルーティングされる。Postgresが必要なら fly pg create でマルチリージョンPostgres(WALレプリケーション)が立つ。

3.2 Flyの強み

• ベアメタルに近い性能。 Firecracker microVMがコンテナの上に薄く一層乗るだけ。
• 30以上のリージョン。 AWS・GCPより小さいが、PaaSカテゴリでは圧倒的。
• GPUサポート(2024年追加)。 A100・L40S・H100を時間単位で借りられる。
• WireGuardベースのプライベートネットワーク。 インスタンス同士がIPv6で直接通信。
• 合理的な価格。 小さなインスタンスは月2〜5ドルから。

3.3 Flyの弱み

• PaaSにしては運用負担が大きい。 Fly Postgresはマネージド DBではなく「Flyが管理してくれるStolon Postgres」だ。バックアップ監視を自分でやる必要がある、というユーザーレポートが多い。
• 公式UIよりCLI中心。 flyctl が中心で、ダッシュボードは補助。
• 課金事故があった。 2023年の課金ポリシー変更で一部ユーザーに請求問題が発生し、信頼回復に時間がかかった。

3.4 誰が選ぶべきか

• グローバルユーザーベースを持つSaaS。
• ゲームバックエンド・リアルタイム通信サーバーなど、レイテンシが核心となるワークロード。
• GPUが必要な小さなAIサービス(Cog・BentoMLコンテナ)。
• Dockerイメージを手元に持っていてインフラのコントロールを望むチーム。

4章 · Render — Heroku代替の正解

Renderは2026年現在 「最もHerokuらしい新PaaS」 だ。2019年創業、2022年シリーズB 5000万ドル、2025年シリーズCで本格的なエンタープライズへ。

4.1 Renderのモデル

• Web Service。 HTTPトラフィックを受けるコンテナ。
• Background Worker。 Sidekiq・Celery・BullMQのようなキューワーカー。
• Cron Job。 スケジューラー。
• Static Site。 SPA・静的サイトホスティング。
• Private Service。 外部公開のない内部サービス。
• PostgreSQL / Redis / Key Value。 マネージドデータ層。

render.yaml(Render Blueprint)一つでインフラ全体をコードとして宣言できる。Herokuの app.json が進化した形に近い。

services:
  - type: web
    name: api
    runtime: docker
    dockerfilePath: ./Dockerfile
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: api-db
          property: connectionString

databases:
  - name: api-db
    databaseName: api
    plan: standard

4.2 Renderの強み

• PaaSらしさ。 Vercelと同じくらい滑らかで、Herokuより現代的だ。
• 公式マネージドPostgres・Redis。 バックアップ・HA・暗号化がデフォルト。
• Preview Environment。 PRごとにDB込みのフルスタックプレビュー。
• 合理的な価格。 Web Service Starterは月7ドル、静的サイトは無料。

4.3 Renderの弱み

• リージョンが少ない。 Oregon・Ohio・Frankfurt・Singaporeなど約5つ。Vercel・Flyより少ない。
• コールドスタート。 Free・StarterプランのWeb Serviceはアイドル時にスリープする。
• ログ・メトリクスは基本レベル。 Datadog・Grafana連携は自分でやる。

4.4 誰が選ぶべきか

• Rails・Django・Expressのような伝統的なモノリシックバックエンド。
• Herokuから移行したいチーム。
• ダッシュボードと自動化の両方が必要な中小SaaS。

5章 · Railway — 使いやすさの強者、2024年シリーズB再調達

Railwayは使いやすさだけで愛される。2024年5月にシリーズB 2000万ドルを調達し「PaaSは死んでいない」を証明した。

5.1 Railwayのモデル

• 全てが「サービス」だ。Postgres・Redis・MongoDB・RabbitMQもただのサービス。
• サービスをGUIでドラッグして繋ぐ。
• 環境変数がサービス間で参照される(POSTGRES_URL をPostgresサービスから直接取る)。
• Railway製の Nixpacks(Buildpacksの後継)がDockerfileなしで大半の言語をビルドする。

5.2 Railwayの強み

• セットアップが最も滑らか。 GitHub接続 → リポ選択 → 完了。
• フルスタックが一画面。 バックエンド・DB・ワーカー・cronが一つのボードに。
• 公式テンプレートが豊富。 Plausible・n8n・Outline・Ghostなどワンクリックデプロイ。
• 使用量ベースの価格。 使わなければ払わない。

5.3 Railwayの弱み

• リージョンが少ない。 US-West・US-East・EU・Asia。Vercel・Flyより少ない。
• サービス当たりの上限。 単一サービスのvCPU・メモリ上限がマネージドクラウドより低い。
• 使用量ベースで請求予測が難しい。 トラフィック急増時に請求がジャンプ。

5.4 誰が選ぶべきか

• サイドプロジェクト・MVP・ハッカソン。
• フルスタックを素早く作りたい個人開発者。
• Discordボット・Telegramボット・自動化ボットのホスティング。

6章 · Cloudflare Pages + Workers + R2 — フルスタックエッジの完成

CloudflareはPaaS市場へ最も遅く、そして最も違うモデルで入ってきた。2026年のCloudflareスタックは フルスタックエッジ と呼べる。

6.1 Cloudflareスタックの構成

• Pages — 静的サイト・SPAホスティング + Functions(サーバーレス)。
• Workers — エッジV8 isolate。グローバル300以上のPOPで実行。
• R2 — S3互換オブジェクトストレージ。エグレス無料 が決定打。
• D1 — エッジで動くSQLite(読み取りレプリカをグローバル複製)。
• KV / Durable Objects / Queues / Vectorize — エッジデータプリミティブのフルセット。

6.2 Cloudflareの強み

• エグレスコスト0。 R2がAWS S3の価格モデルを壊した。
• グローバルエッジ。 300以上のPOP。どこからでも近い。
• コールドスタートがほぼない。 V8 isolateはミリ秒で起動。
• 無料枠が寛大。 Workers日10万リクエスト無料、Pagesは静的無制限。

6.3 Cloudflareの弱み

• Node.js互換性が部分的。 node:fs, node:net のようなモジュールが制限される(nodejs_compat フラグで一部補強)。
• 単一リクエストのCPU時間制限。 Free 50ms / Paid 30秒。重い同期処理には不向き。
• D1はまだグローバル書き込み分散ができない。 プライマリリージョン1個+グローバル読み取りレプリカモデル。
• ベンダーロックイン。 Durable Objects・KV・QueuesはCloudflareの外で再現できない。

6.4 誰が選ぶべきか

• 静的アセットがトラフィックの大半を占めるサイト(ブログ・ドキュメント・ランディング)。
• Astro・Remix・Hono・Next.js(アダプター)で作ったエッジ親和アプリ。
• 画像・動画ホスティングの多いサービス(R2エグレス無料)。
• グローバルユーザー、コールドスタート最小化が重要なワークロード。

7章 · Netlify — JAMstackの先駆者、コンポーザブルなフルスタックへ

Netlifyは2014年にJAMstackを命名した会社だ。2026年のNetlifyはそのアイデンティティにフルスタック機能を加える。

7.1 Netlifyの現在

• Netlify Edge Functions。 Denoベース。Cloudflare Workersに似たエッジランタイム。
• Functions。 AWS Lambda上のサーバーレス。
• Forms。 フォームデータの受信+スパムフィルタリングが組み込み。
• Identity / Authentication。 GoTrueベース。
• Composable Web。 Headless CMS・Commerce・Auth・Searchを束ねるコンポーザブルプラットフォームの概念。

7.2 Netlifyの強み

• 静的サイトの標準。 Jekyll・Hugo・Astro・Gatsby・Next.js Exportが全て滑らかに動く。
• Build Plugins。 ビルドパイプラインをnpmパッケージで拡張可能。
• フォーカスが明確。 マーケティングサイト・ブログ・ドキュメント・Eコマースのフロントエンド。

7.3 Netlifyの弱み

• Next.jsの新機能サポートがVercelより遅い。 PPR・Streaming RSCが1〜2四半期遅れる。
• 長時間実行バックエンドに不向き。 関数の最大時間制限が短い。
• 価格が急速に上がる。 ビルド時間がトラフィックより早く請求額を伸ばす。

7.4 誰が選ぶべきか

• マーケティング・ブログ・ドキュメントサイト。
• Next.js以外のメタフレームワーク(Astro・Eleventy・Hugo)を使うチーム。
• フォーム・Identity組み込みが必要な非技術運用者。

8章 · Coolify(OSS)— セルフホスティングのVercel

Coolifyは2026年、OSSセルフホスティングPaaSの事実上の標準になった。2024年のシードラウンドでフルタイム開発が始まり、GitHubスターは4万を超えた。

8.1 Coolifyのモデル

• 一行のインストールスクリプトでVPSに入れる。
• GitHub・GitLabとOAuthで接続。
• リポを選ぶとNixpacks・Dockerfile・Composeを自動検出。
• PRを開けばプレビューURLが自動生成される。
• Postgres・MySQL・Redis・MongoDBをGUIクリックで立てる。
• Traefikが自動SSL(Let's Encrypt)+リバースプロキシ。

8.2 Coolifyの強み

• 完全セルフホスティング。 Hetzner CX22(月4ユーロ)に入れれば5つのプロジェクトが余裕で回る。
• UXが滑らか。 Vercelを真似たことを誇っている。
• 公式テンプレート。 Plausible・Umami・Outline・Ghost・n8nなどワンクリックデプロイ。
• データ主権。 DBが自分のVPSにある。GDPR・企業ポリシーに有利。

8.3 Coolifyの弱み

• 運用責任は自分。 ディスクフル・OOM・SSL期限切れを自分で見る。
• HAが難しい。 ノード1個が死ぬと全サービスが死ぬ。マルチノードはベータ。
• バックアップは別。 自分でcronで pg_dumpall をS3へ送る。

8.4 誰が選ぶべきか

• サイドプロジェクト5〜20個を1台のVPSで回したい開発者。
• GDPR・HIPAA・国内ポリシーでマネージドクラウドが使えないチーム。
• 月100〜200ドルを節約したい小さなスタートアップ。

9章 · Dokploy(OSS)— Coolify対抗馬

Dokployは2024年に登場したCoolifyの対抗馬だ。2026年5月時点でGitHubスターは2万を超え、「Coolifyが重く感じた人々」が集まる。

9.1 Dokploy対Coolify

Dokployはマルチサーバーサポートが正式機能で入った点が差別化要素だ。Coolifyはマルチノードをベータに据えている。

9.2 誰が選ぶべきか

• TypeScriptに慣れたチーム(コントリビューションを考えるなら)。
• 複数サーバーに分散して運用したいチーム。
• Coolifyを試したがより軽いものを望む人。

10章 · Kamal 2(37signals)— 自分のサーバーへデプロイ

KamalはPaaSではない。コンテナデプロイツール だ。37signals(Basecamp・Hey)がAWSを離れる中で作った道具で、2024年にKamal 2が出た。

10.1 Kamalの哲学

• 自分が買ったサーバー(Hetzner・OVH・自社データセンター)にコンテナを入れる。
• PaaSの抽象はない。サーバー・ドメイン・SSLを自分で知る。
• kamal deploy で無停止デプロイ・ロールバック。
• Traefikの代わりにKamal-proxy(自前の小さなプロキシ)を使う。
• Rails 7.2からデフォルトのデプロイツール。

10.2 deploy.yml の例

service: hey
image: 37signals/hey

servers:
  web:
    - 192.168.0.1
    - 192.168.0.2
  job:
    hosts:
      - 192.168.0.3
    cmd: bin/jobs

registry:
  server: ghcr.io
  username: my-org
  password:
    - KAMAL_REGISTRY_PASSWORD

env:
  secret:
    - RAILS_MASTER_KEY
    - DATABASE_URL

この一つのファイルで kamal setup → kamal deploy が可能だ。

10.3 Kamalの強み

• 運用コストが最も安い。 同じトラフィックでAWSの1/10、Herokuの1/5程度。
• ベンダーロックインは0。 SSHが通るクラウドならどこでもOK。
• DHH哲学の検証。 Basecamp・Heyが実際にこれで動いている。
• 2025年ONCE / Campfire — Kamal上で動くセルフホスティングSaaSが検証されたモデルになった。

10.4 Kamalの弱み

• PaaSのUXはない。 プレビュー環境・自動DBプロビジョニングはない。
• 本当にサーバーを運用することになる。 セキュリティパッチ・ファイアウォール・監視。
• HAを自分で設計する。 自動フェイルオーバーはない。

10.5 誰が選ぶべきか

• モノリシックなRails・Django・Laravelを運用するチーム。
• 既にAWS・Herokuに月1000ドル以上使っているチーム。
• インフラ管理権限がポリシーで要求される企業。

11章 · Northflank / Sevalla / Caprover / Easypanel — その他のPaaS

11.1 Northflank — Kubernetes PaaSの頂点

Northflankは「KubernetesをPaaSのUXで包む」が最もうまくできているプラットフォームだ。2026年現在、マネージドPaaSカテゴリで最も重いワークロードを受ける一つ。

• 複数クラウド(AWS・GCP・Azure)上にデプロイ。
• GPUワークロード正式サポート。
• マイクロサービスのトポロジーグラフ。
• 自分のクラウドアカウントへBYOC(Bring Your Own Cloud)可能。

対象: コンテナ30個以上・複雑なマイクロサービス・企業コンプライアンスが必要なチーム。

11.2 Sevalla — Kinstaの新PaaS

SevallaはマネージドWordPressホスティングで有名なKinstaが2024年にリリースした新PaaSだ。Google Cloud上に作られ、「Vercel・Renderの隙間」を狙う。

• 世界30以上のGCPリージョン。
• 静的サイト・アプリ・DB・オブジェクトストレージが全て一つのプラットフォーム。
• 静的サイト100個無料、合理的なアプリ価格。

対象: WordPress・LaravelなどPHP・Nodeを幅広く運用するエージェンシー。

11.3 Caprover — 最も古いセルフホスティングPaaS

Caproverは2017年登場。Docker Swarmベース。Coolifyが現れる前まではセルフホスティングPaaSの標準だった。今もGitHubスター13k+、安定して動く。

• Docker Swarm。
• ワンクリックアプリ200以上。
• Caprover-CLIでCI/CD統合。

対象: 昔から使ってきた人・Docker Swarmをあえて使うチーム。

11.4 Easypanel — 軽量セルフホスティング

Easypanelは2022年登場。Docker Composeベース。Coolifyより軽く、UIがクリーン。

• Docker Compose。
• テンプレート100以上。
• 無料 / Pro(月19ドル)。

対象: 1台のVPSで3〜5アプリをきれいに回したい1人開発者。

12章 · Heroku — 一時代を過ぎた巨人

Herokuは2026年現在もまだ生きている。2022年の無料廃止でユーザーを失ったが、エンタープライズSalesforce顧客ベースの上で動いている。2025年にはIBMがHeroku買収を検討中という報道が出たが、2026年5月現在、確定発表はない。

12.1 Herokuの現在

• Mini Dyno 月5ドルで無料の空席を埋める。
• Heroku Postgres・Redis 今もマネージドデータの標準。
• Add-onマーケットプレイス が生きている(Logentries・Papertrail・NewRelic)。
• 2024年GAされたFir Generation Platform — コンテナベースの次世代ランタイム。

12.2 Herokuの価値

• 安定性。17年間動いてきた。
• 既存のHerokuアプリがあるなら、移行コストより維持の方が安い。
• Salesforce統合が必要なエンタープライズに意味がある。

12.3 新しく始めるなら?

新しいサイドプロジェクトをHerokuに入れるなら、それはノスタルジーだ。Render・Railway・Coolifyが同じことをより安くより良くやる。ただし職場で既にHerokuを使っているなら、過去の判断が間違っていたとは限らない。

13章 · 韓国・日本 — Kakao i Cloud, Naver NCP, さくら, KAGOYA, ConoHa

グローバルPaaSが全てではない。韓国と日本には独自のPaaS・VPSエコシステムがある。

13.1 韓国 — Kakao i Cloud / Naver NCP

• Kakao i Cloud。 カカオのクラウド。2022年ローンチ。韓国ユーザーデータ主権に強い。ただしPaaSの抽象はAWSに近い。
• Naver Cloud Platform(NCP)。 ネイバーのクラウド。韓国政府・公共・金融に強い。コンテナ・Kubernetesサービスが正式。
• NHN Cloud。 ハンゲーム・PAYCOの運用ノウハウベース。韓国企業に親和的。

韓国スタートアップがマネージドPaaSを使うなら、グローバルユーザーベースを持つ場合はVercel・Render・Flyが先、韓国内部ユーザー中心ならNaver NCP・Kakao i Cloudが効率的。

13.2 日本 — さくら・KAGOYA・ConoHa・Heroku Japan

• さくらクラウド(Sakura Cloud)。 日本の自国クラウド。データセンターが日本国内にあり、政府・金融に親和的。
• KAGOYA CLOUD。 VPS市場の強者。月590円から始まる低価格VPS。
• ConoHa。 GMOグループ。WordPress・Minecraftホスティングで有名。
• Heroku Japan。 Salesforce Japan傘下。日本語サポート+東京リージョン。

日本の開発者のサイドプロジェクトの流れは「KAGOYA・ConoHa VPS + Coolify・Dokploy」が2026年の新標準になった。

14章 · 誰が何を選ぶべきか — サイドプロジェクト / スタートアップ / グローバル / コスト重視

14.1 サイドプロジェクト

• 0ドルで始める。 Cloudflare Pages + Workers + R2。無料枠が最も寛大。
• 5ドル以内。 Hetzner CX22 + Coolify。プロジェクト5〜10個を一度に。
• Next.jsだけ。 Vercel Hobby。無料+トラフィック制限。
• Discordボット・自動化。 Railwayの使用量ベース。

14.2 初期スタートアップ(シード段階)

• 素早い市場参入。 Vercel + Supabase / Neon + Resend。インフラを気にしない。
• モノリシックRails・Django。 Render。Herokuに似た安定感。
• グローバルユーザー。 Fly.io + Postgres。最初からマルチリージョンが必要。
• コスト重視。 Hetzner + Coolify + Cloudflare CDN。月20ドル以内でシリーズAまで行ける。

14.3 シリーズA〜Bスタートアップ

• Vercel・Fly・Renderのいずれか + 別途マネージドDB(Neon・Supabase・PlanetScale)。
• 可観測性を分離。 Datadog・Grafana Cloud・Axiom・Better Stack。
• CDN/WAFはCloudflareへ。 2層モデルが標準になった。

14.4 グローバルユーザー / エッジ

• 静的アセット中心。 Cloudflare Pages + R2。
• 動的API。 Fly.ioマルチリージョンまたはVercel Edge Functions。
• DB。 Neon(サーバーレスPostgres)/ Turso(エッジSQLite)/ PlanetScale。

14.5 コスト重視(1人開発者 / ブートストラップ)

• Hetzner CX22(月4ユーロ)+ Coolify が事実上の正解。
• 無料Cloudflare CDN / WAF。
• Cloudflare R2 でオブジェクトストレージ(エグレス無料)。
• バックアップ はGitHub Actions cronで pg_dumpall → R2。

この組み合わせなら月10ドル以内で5〜20プロジェクトが回る。2026年のブートストラッパー標準。

14.6 韓国・日本のローカルユーザー中心

• 韓国: Naver NCP + 自前のマネージドDB。
• 日本: さくらクラウド + さくらのオブジェクトストレージ。
• サイドプロジェクト: KAGOYA / ConoHa VPS + Coolify。

15章 · 決定木 — 30秒で選ぶ

サイドプロジェクト? 月0〜5ドル?
├── Next.jsだけ → Vercel Hobby
├── フルスタック+DB → Railway(使用量ベース)
├── 5個以上 → Hetzner + Coolify
└── 静的+エッジ → Cloudflare Pages

スタートアップMVP? 月20〜100ドル?
├── Next.js → Vercel Pro + Neon
├── Rails/Django → Render
├── マルチリージョン → Fly.io
└── コスト最優先 → Coolify on Hetzner + Cloudflare

成長期? 月500ドル以上?
├── そのまま続けて分離を始める
├── DBはマネージド外部(Neon / Supabase / PlanetScale)
├── 可観測性はDatadog / Grafana / Axiom
└── CDN/WAFはCloudflare

エンタープライズ?
├── 自社クラウドBYOC → Northflank
├── 自社データセンター → Kamal 2 + 自社K8s
└── コンプライアンス → AWS/Azure/GCP直接

参考 / References

• Vercel — Fluid Compute公式発表(2024.08)
• Vercel — Next.js 15 App Router
• Fly.io — Fly Machines
• Fly.io — GPU on Fly
• Render — Render Blueprints (render.yaml)
• Render — Preview Environments
• Railway — Series B 2024 (TechCrunch)
• Railway — Nixpacks
• Cloudflare — Pages
• Cloudflare — Workers Runtime APIs
• Cloudflare — R2 (egress-free storage)
• Cloudflare — D1 SQLite
• Netlify — Edge Functions
• Netlify — Composable Web
• Coolify — 公式サイト
• Coolify — GitHubリポジトリ
• Dokploy — 公式サイト
• Dokploy — GitHubリポジトリ
• Kamal — 公式サイト
• Kamal — Kamal 2発表(37signals 2024)
• 37signals — Leaving the cloud (2023)
• Heroku — Fir Generation Platform
• Heroku — Pricing (Post-Free 2022)
• Northflank — 公式サイト
• Sevalla — 公式サイト(Kinsta)
• Caprover — 公式サイト
• Easypanel — 公式サイト
• Naver Cloud Platform — 公式サイト
• Kakao i Cloud — 公式サイト
• さくらインターネット — 公式サイト
• KAGOYA CLOUD — 公式サイト
• ConoHa — 公式サイト
• Hetzner — Cloud Pricing