Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 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

項目CoolifyDokploy
初登場20202024
GitHubスター(2026.05)40k+20k+
コア言語PHP(Laravel)TypeScript(Next.js)
データベースPostgresPostgres
リバースプロキシTraefikTraefik
マルチサーバーベータ正式
価格無料 / クラウド無料 / クラウド

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

Discuss on Twitter • View on GitHub