DEV Community

スシロー
スシロー

Posted on

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

#saas #devops #tutorial #webdev

結論（おすすめ1つ）

Renderに乗り換えることを推奨する。

理由は3点。GitHubとの連携が最もシンプルでHerokuからの移行コストが最小、ゼロダウンタイムデプロイがデフォルトで有効、そしてPostgreSQLマネージドDBがそのまま使える点でHerokuのアドオン体験に最も近い。Railway・Fly.ioが向く場面は後述するが、「とにかく早く移行したい」チームにはRenderが第一選択になる。

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

項目 Render Railway Fly.io
無料枠 あり（一定時間スリープ）公式の料金ページで要確認 あり（クレジット制）公式の料金ページで要確認 あり（小規模VM）公式の料金ページで要確認
従量課金 リソースベース 使用量ベース インスタンスベース
PostgreSQL マネージドあり プラグインで追加 Fly Postgres（自己管理に近い）
移行コスト 低（Procfile互換） 低〜中 中〜高（Dockerfile必須）
対応言語 Node/Python/Ruby/Go/Rust/Java/静的サイト等 同左＋Nixpacksで広範囲 Dockerコンテナなら何でも
カスタムドメイン 無料プランから対応 対応 対応
マルチリージョン 限定的 限定的 ネイティブ対応（強み）
CLI成熟度 標準的 標準的 高い（fly CLIが強力）

料金の具体的な金額は各社の公式料金ページで必ず確認すること。2024年以降、各社の無料枠は変更が頻繁なため、本記事では金額を記載しない。

移行手順

ここではHeroku上のNode.jsアプリをRenderへ移行する手順を示す。

Step 1: Renderアカウント作成とGitHub連携

# Render CLIのインストール（任意、WebUIでも可）
npm install -g @render-com/cli
render login
Enter fullscreen mode Exit fullscreen mode

Step 2: render.yaml をリポジトリルートに配置

# render.yaml
services:
  - type: web
    name: my-app
    env: node
    buildCommand: npm install && npm run build
    startCommand: npm start
    envVars:
      - key: NODE_ENV
        value: production
      - key: DATABASE_URL
        fromDatabase:
          name: my-db
          property: connectionString

databases:
  - name: my-db
    databaseName: myapp
    user: myapp
Enter fullscreen mode Exit fullscreen mode

Step 3: Herokuの環境変数をエクスポート

# Heroku CLIで既存の環境変数を一覧取得
heroku config --app your-heroku-app-name

# 必要な変数をRenderのDashboard > Environment に手動で貼り付けるか、
# Render CLIで設定する
render env set KEY=VALUE --service my-app
Enter fullscreen mode Exit fullscreen mode

Step 4: Heroku PostgreSQLのデータをマイグレーション

# Herokuからダンプを取得
heroku pg:backups:capture --app your-heroku-app-name
heroku pg:backups:download --app your-heroku-app-name

# RenderのPostgreSQLへリストア
pg_restore --verbose --clean --no-acl --no-owner \
  -d "$RENDER_DATABASE_URL" latest.dump
Enter fullscreen mode Exit fullscreen mode

Step 5: デプロイ確認

# GitHubへpushするだけで自動デプロイが走る
git push origin main

# デプロイログを確認
render logs --service my-app --tail
Enter fullscreen mode Exit fullscreen mode

Heroku Procfile はそのまま使える場合が多い

# Procfile（変更不要なケースが多い）
web: npm start
worker: node worker.js
Enter fullscreen mode Exit fullscreen mode

向き不向き

Renderが向くチーム・用途

  • HerokuからProcfileベースでそのまま移行したい小〜中規模チーム
  • フロントエンド静的サイト＋バックエンドAPIを同一プラットフォームで管理したい場合
  • PostgreSQLのマネージドサービスをHerokuと同様の感覚で使いたい場合
  • インフラ専任者がいない、あるいは少人数でDevOpsを回しているチーム

Railwayが向くチーム・用途

  • テンプレートからすばやくプロトタイプを立ち上げたい個人開発者
  • Nixpacksによる自動ビルド検出でDockerfileを書きたくない場合
  • 複数サービスをプロジェクト単位でまとめて管理したい場合

Fly.ioが向くチーム・用途

  • マルチリージョン展開が必要で、ユーザーの地理的分散が大きいプロダクト
  • DockerfileやOCI準拠コンテナを既に持っており、インフラ制御を細かくしたいチーム
  • WebSocketやgRPCなど長期コネクションが必要なアプリ（Anycastルーティングの恩恵を受けやすい）

避けるべきケース

  • Render: 無料プランのスリープ仕様が許容できないAPI（常時起動が必要なら有料プランへ）
  • Railway: クレジット制の消費ペースが読みにくいため、トラフィックが急増するプロダクトは費用予測が困難
  • Fly.io: Dockerfile管理やfly CLIの習熟コストが高く、インフラ経験が浅いチームには初期ハードルになる。また自己管理に近いPostgresは運用コストを過小評価しやすい

Top comments (0)