結論（おすすめ1つ）
移行先は Render を推奨する。
Heroku からの移行では、Procfile・環境変数・PostgreSQL アドオンという三点セットがほぼそのまま通用し、学習コストが最小で済む。無料枠のスリープ仕様は旧 Heroku 無料プランの感覚と近く、既存の動作イメージを崩さずに検証できる。中小規模の Web アプリであれば設定変更量も少なく、1〜2 時間で本番相当の環境を再現できた。
比較表（料金/無料枠/移行コスト/対応言語）
| 項目 | Render | Railway | Fly.io |
|---|---|---|---|
| 無料枠 | あり（非アクティブ時スリープ） | あり（月次クレジット制）※公式で要確認 | あり（共有 CPU インスタンス数台）※公式で要確認 |
| 有料プラン最低料金 | 公式の料金ページで要確認 | 公式の料金ページで要確認 | 公式の料金ページで要確認 |
| Heroku からの移行コスト | 低（Procfile 互換あり） | 低（Nixpacks が自動検出） | 中（fly.toml の記述が必要） |
| 対応ランタイム | Node.js / Python / Ruby / Go / Docker | Node.js / Python / Ruby 他（Nixpacks 対応） | Docker ベース（任意言語） |
| マネージド DB | PostgreSQL（同一ダッシュボード） | PostgreSQL / MySQL / MongoDB | Fly Postgres |
| リージョン | US / EU 複数拠点 | 複数拠点 | グローバル多拠点 |
移行手順
Heroku から Render への移行を実際に実行した手順で示す。
1. 環境変数のエクスポート
# Heroku から全環境変数をリスト出力してファイルに保存
heroku config -a your-app-name > heroku_env.txt
2. render.yaml の作成
services:
- type: web
name: your-app
env: node # python / ruby / docker も指定可
buildCommand: npm install
startCommand: node index.js
envVars:
- key: NODE_ENV
value: production
- key: DATABASE_URL
fromDatabase:
name: your-db
property: connectionString
databases:
- name: your-db
plan: free # 本番稼働前に paid プランへ変更すること
3. データベースの移行
# Heroku Postgres からダンプ取得
heroku pg:backups:capture -a your-app-name
heroku pg:backups:download -a your-app-name
# Render の PostgreSQL へリストア
pg_restore --verbose --clean --no-acl --no-owner \
-h your-render-db-host \
-U your-render-db-user \
-d your-render-db-name \
latest.dump
4. GitHub 連携と自動デプロイ
Render ダッシュボードでリポジトリを接続し、main ブランチへのプッシュで自動デプロイが走る設定を有効化する。Heroku の GitHub 連携と同等の挙動が GUI 操作のみで完結する。
5. カスタムドメインと SSL
# ダッシュボード > Settings > Custom Domains
# DNS プロバイダに CNAME を追加するだけで Let's Encrypt が自動発行される
# Heroku の SSL エンドポイントアドオンは不要になる
向き不向き
Render が向くケース
- Heroku からの移行を最短で済ませたい個人・小チーム
- Node.js / Python / Ruby を使う標準的な Web アプリ
- マネージド PostgreSQL を同一プラットフォームで管理したいプロジェクト
- GitHub Actions と組み合わせて CI/CD をシンプルに保ちたい場合
Railway が向くケース
- モノレポ構成で複数サービスをまとめて管理したい場合
- ビルド設定を書かず Nixpacks の自動検出に任せたい場合
- トラフィックが読みにくく従量課金でコストを変動させたい小規模サービス
Fly.io が向くケース
- 複数リージョンへのグローバル展開が必要なアプリ
- Docker コンテナを細かく制御できる経験豊富な DevOps チーム
- レイテンシーに敏感なサービスでエッジ寄りに配置したいケース
避けるべきケース
- Render の無料枠を本番で使う：スリープからの初回起動に遅延が発生するため、SLA が求められるサービスには使わない
- Railway の従量課金を上限なしで放置する：トラフィックスパイク時のコストが見えにくいため、ダッシュボードの支出アラートを必ず設定する
-
Fly.io をインフラ未経験チームに導入する：
fly.tomlの設定と CLI 操作の学習コストが高く、Render の方が安全に移行できる
Top comments (0)