結論（おすすめ1つ）
Render への移行を推奨する。
Heroku の Dyno モデルに最も近い設計思想を持ち、既存の Procfile ベースのアプリをほぼそのまま持ち込める。管理画面の UX が直感的で、環境変数・PostgreSQL アドオンの移行が他の2サービスより手間が少ない。Railway・Fly.io と比べると多リージョン展開の柔軟性では劣るが、「Heroku から脱出したいだけ」という要件ならば学習コスト最小で移行を完了できる。
比較表（料金/無料枠/移行コスト/対応言語）
| 項目 | Render | Railway | Fly.io |
|---|---|---|---|
| 料金体系 | プラン制 | 使用量課金 | 使用量課金 |
| 具体的な料金 | 公式の料金ページで要確認 | 公式の料金ページで要確認 | 公式の料金ページで要確認 |
| 無料枠 | あり（非アクティブ時に Spin-down） | 限定的（公式ページで要確認） | あり（VM・帯域に上限） |
| Heroku からの移行コスト | 低（Procfile 互換） | 中（railway.toml 作成が必要） | 高（Dockerfile + flyctl 設定が必要） |
| 対応言語/ランタイム | Node / Python / Ruby / Go / Docker ほか | Node / Python / Ruby / Java / Docker ほか | Docker ベース（言語不問） |
| マネージド DB | PostgreSQL / Redis | PostgreSQL / MySQL / Redis | Fly Postgres / Redis |
| 日本近傍リージョン | シンガポール | シンガポール | 東京（nrt）あり |
移行手順
1. Render CLI のインストールと認証
npm install -g @render-com/cli
render login
2. render.yaml を作成する（Procfile の置き換え）
# render.yaml
services:
- type: web
name: my-app
runtime: node
buildCommand: npm install && npm run build
startCommand: node server.js
envVars:
- key: NODE_ENV
value: production
- key: DATABASE_URL
fromDatabase:
name: my-db
property: connectionString
databases:
- name: my-db
plan: free
3. 環境変数を Heroku から書き出す
heroku config -a your-heroku-app --json > heroku_env.json
# シークレット類を確認したうえで Render ダッシュボードの
# Environment タブへ貼り込む
4. PostgreSQL データを移行する
# Heroku 側でダンプを取得
heroku pg:backups:capture -a your-heroku-app
heroku pg:backups:download -a your-heroku-app
# Render の DB へリストア（接続 URL はダッシュボードで確認）
pg_restore --no-acl --no-owner -d "$RENDER_DATABASE_URL" latest.dump
5. GitHub 連携と自動デプロイを有効化する
Render ダッシュボードでリポジトリを接続すると、main ブランチへの push で自動デプロイが起動する。カスタムドメインと TLS も同画面で設定できる。
向き不向き
Render が向くチーム・規模
- Heroku からの移行だが設定変更を最小限にしたい個人・小規模チーム
- Rails / Express など既存の Buildpack 系アプリをそのまま動かしたいケース
- インフラ知識が浅いメンバーも管理画面だけで運用したいチーム
Railway が向くケース
- 「作って試して壊す」サイクルを高速で回したいスタートアップ
- アイドル時間にコストをかけたくなく、従量課金を好む小規模サービス
- モノレポ内の複数マイクロサービスをまとめて管理したい場合
Fly.io が向くケース
- 東京リージョン（nrt）での低レイテンシが必須要件のサービス
- Docker コンテナを細かく制御したい、またはマルチリージョン展開を前提とした設計
- Elixir / Phoenix など Fly.io が公式サポートするエコシステムを使っているチーム
避けるべきケース
- Render 無料枠: Spin-down があるため、常時応答が求められる本番 API には不向き。有料プランへのアップグレードを検討する
- Railway: 従量課金の上限設定を怠ると予期しないコストが発生しうる。公式ドキュメントのスペンドリミット設定を必ず確認すること
-
Fly.io:
flyctlのラーニングカーブが高く、Heroku 的な「ゼロ設定で動く」体験は期待できない。Docker の扱いに慣れていないチームには向かない
Top comments (0)