スシロー

Posted on Jul 3

【2026】Heroku 代替 2026 (Render/Railway/Fly.io)：料金・移行コストで選ぶ

#saas #devops #tutorial #webdev

結論（おすすめ1つ）

Render を選ぶ。

Heroku からの移行先として、まず Render を試すべきだ。Git push ベースのデプロイフロー・render.yaml による Infrastructure as Code・PostgreSQL や Redis の managed サービスが一通り揃っており、Heroku の開発体験を最も忠実に再現できる。既存の Procfile と環境変数の移し替えだけで動くことが多く、移行コストが三者の中で最も低い。Railway も UI の完成度が高く甲乙つけがたいが、Render の方がドキュメントが充実しており、チーム運用時のトラブルシュートが楽だった。

比較表（料金/無料枠/移行コスト/対応言語）

項目	Render	Railway	Fly.io
料金モデル	使用量ベース	使用量ベース	使用量ベース
無料枠	静的サイトは無料枠あり。Web サービスは公式の料金ページで要確認	Hobby プランに月次クレジットあり（公式要確認）	一定リソース内は無料枠あり（公式要確認）
移行コスト	低：`Procfile` → `render.yaml` への変換がほぼ不要	低〜中：GUI 操作中心、設定ファイルは任意	中：`fly.toml` と Dockerfile の準備が必要
対応言語	Node / Python / Ruby / Go / Rust / PHP 他	Node / Python / Ruby / Go / Java 他	Docker があれば原則なんでも可
Managed DB	PostgreSQL, Redis	PostgreSQL, MySQL, Redis 他	PostgreSQL（外部アドオン連携）
カスタムドメイン + TLS	あり（自動発行）	あり（自動発行）	あり（自動発行）
CDN / 静的配信	あり	あり	あり（Anycast エッジ）

移行手順

Heroku → Render（推奨ルート）

ステップ 1: 環境変数を退避

# Heroku の環境変数を JSON でエクスポートしておく
heroku config -a <YOUR_APP> --json > heroku_env.json

ステップ 2: render.yaml をリポジトリルートに作成

services:
  - type: web
    name: my-app
    runtime: node        # python / ruby / go など用途に合わせて変更
    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: starter        # 本番は有料プランを公式で確認

ステップ 3: 環境変数をインポート

# Render CLI を使う場合（brew install render でインストール可）
render env set --service my-app \
  SECRET_KEY=xxxx \
  API_KEY=yyyy
# 件数が多いときはダッシュボードの「Bulk Paste」が速い

ステップ 4: PostgreSQL データを移行

# Heroku Postgres からダンプ取得
heroku pg:backups:capture -a <YOUR_APP>
heroku pg:backups:download -a <YOUR_APP>  # latest.dump が生成される

# Render の PostgreSQL へリストア
pg_restore --verbose --no-acl --no-owner \
  -h <RENDER_DB_HOST> \
  -U <RENDER_DB_USER> \
  -d <RENDER_DB_NAME> \
  latest.dump

ステップ 5: GitHub 連携して自動デプロイを有効化

Render ダッシュボードで New + → Web Service を選択し、対象リポジトリを接続する。ブランチを指定すれば以後は push のたびに自動デプロイが走る。render.yaml があれば設定はそこから読み込まれる。

向き不向き

Render が向くケース

Heroku から最小工数で移行したい個人・小規模チーム
Ruby on Rails / Django / Express など王道フレームワーク中心の構成
render.yaml でインフラをコードとして管理・レビューしたい

Railway が向くケース

GUI ファーストで設定ファイルを書きたくない非インフラエンジニア
複数のマイクロサービスを一画面でまとめて管理したい
プロトタイプや PoC など、デプロイ速度を最優先するフェーズ

Fly.io が向くケース

既存の Docker イメージをそのままデプロイしたい
グローバルユーザー向けにレイテンシを最小化したい（Anycast によるエッジ分散）
Kubernetes は重いが、コンテナリソースを細かく制御したいチーム

避けるべきケース

Render: CPU バウンドな長時間バッチ。無料・低価格プランはリソース上限に当たりやすい
Railway: 大規模トラフィックやエンタープライズ向け SLA が必要な用途（サポート体制を公式で要確認）
Fly.io: Docker 経験がない、または Dockerfile のメンテ工数を割けない小規模チーム
三者共通: 金融・医療など規制産業で厳密なネットワーク分離や監査ログが必要なシステム。各社のコンプライアンス対応範囲を必ず事前確認すること

DEV Community