필사 모드: 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

| 項目 | Coolify | Dokploy |

|------|---------|---------|

| 初登場 | 2020 | 2024 |

| GitHubスター(2026.05) | 40k+ | 20k+ |

| コア言語 | PHP(Laravel) | TypeScript(Next.js) |

| データベース | Postgres | Postgres |

| リバースプロキシ | Traefik | Traefik |

| マルチサーバー | ベータ | 正式 |

| 価格 | 無料 / クラウド | 無料 / クラウド |

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)](https://vercel.com/blog/introducing-fluid-compute)

- Vercel — [Next.js 15 App Router](https://nextjs.org/docs/app)

- Fly.io — [Fly Machines](https://fly.io/docs/machines/)

- Fly.io — [GPU on Fly](https://fly.io/docs/gpus/)

- Render — [Render Blueprints (render.yaml)](https://render.com/docs/blueprint-spec)

- Render — [Preview Environments](https://render.com/docs/preview-environments)

- Railway — [Series B 2024 (TechCrunch)](https://techcrunch.com/2024/05/01/railway-raises-20-million-paas/)

- Railway — [Nixpacks](https://nixpacks.com/)

- Cloudflare — [Pages](https://pages.cloudflare.com/)

- Cloudflare — [Workers Runtime APIs](https://developers.cloudflare.com/workers/runtime-apis/)

- Cloudflare — [R2 (egress-free storage)](https://developers.cloudflare.com/r2/)

- Cloudflare — [D1 SQLite](https://developers.cloudflare.com/d1/)

- Netlify — [Edge Functions](https://docs.netlify.com/edge-functions/overview/)

- Netlify — [Composable Web](https://www.netlify.com/composable-web/)

- Coolify — [公式サイト](https://coolify.io/)

- Coolify — [GitHubリポジトリ](https://github.com/coollabsio/coolify)

- Dokploy — [公式サイト](https://dokploy.com/)

- Dokploy — [GitHubリポジトリ](https://github.com/dokploy/dokploy)

- Kamal — [公式サイト](https://kamal-deploy.org/)

- Kamal — [Kamal 2発表(37signals 2024)](https://world.hey.com/dhh/kamal-2-1ad0d4ef)

- 37signals — [Leaving the cloud (2023)](https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0)

- Heroku — [Fir Generation Platform](https://blog.heroku.com/fir-generation-platform-now-available)

- Heroku — [Pricing (Post-Free 2022)](https://www.heroku.com/pricing)

- Northflank — [公式サイト](https://northflank.com/)

- Sevalla — [公式サイト(Kinsta)](https://sevalla.com/)

- Caprover — [公式サイト](https://caprover.com/)

- Easypanel — [公式サイト](https://easypanel.io/)

- Naver Cloud Platform — [公式サイト](https://www.ncloud.com/)

- Kakao i Cloud — [公式サイト](https://www.kakaocloud.com/)

- さくらインターネット — [公式サイト](https://www.sakura.ad.jp/)

- KAGOYA CLOUD — [公式サイト](https://www.kagoya.jp/cloud/)

- ConoHa — [公式サイト](https://www.conoha.jp/)

- Hetzner — [Cloud Pricing](https://www.hetzner.com/cloud/)