Source: Dev.to

結論（おすすめ1つ）

迷ったら Render に乗り換えるのが無難です。理由は3つ。Heroku に最も操作感が近く（git push デプロイ・buildpack 互換）学習コストが小さいこと、Web/DB/cron/Worker を1サービスで完結でき構成が散らからないこと、render.yaml でインフラをコード管理できて再現性が高いことです。スピード重視で小さく始めるなら Railway、Docker前提で低レイテンシな常時稼働が要るなら Fly.io を検討します。

項目 Render Railway Fly.io

料金 従量＋固定プラン（公式の料金ページで要確認） 従量課金中心（公式の料金ページで要確認） リソース従量（公式の料金ページで要確認）

無料枠 有無・条件は公式の料金ページで要確認 クレジット制（公式の料金ページで要確認） 有無・条件は公式の料金ページで要確認

移行コスト 低（Heroku同等のgit push/buildpack互換） 低（GitHub連携で自動検出） 中（Dockerfile/fly.toml前提）

対応言語 Node/Python/Ruby/Go/Rust/Elixir 等＋Docker Nixpacksで主要言語自動検出＋Docker Dockerで動くものは基本すべて

DB Managed PostgreSQL あり PostgreSQL/MySQL/Redis等 Managed Postgres / LiteFS等

※金額・無料枠の条件は変動するため、各社の公式料金ページで最新の数値を必ず確認してください。 ここでは Heroku → Render の例を示します。まず Heroku 側の環境変数を控えます。

Heroku の現行設定を確認

heroku config -a your-app heroku pg:info -a your-app

リポジトリ直下に render.yaml を置きます。 services:

• type: web name: your-app env: node # python / ruby など適宜 buildCommand: npm install && npm run build startCommand: npm start envVars:
  • key: NODE_ENV value: production
  • key: DATABASE_URL fromDatabase: name: your-db property: connectionString

databases:

• name: your-db plan: free # プラン名・可否は公式の料金ページで要確認

DB を移行します（Heroku Postgres → Render Postgres）。

Heroku からダンプを取得

heroku pg:backups:capture -a your-app heroku pg:backups:download -a your-app # latest.dump が落ちる

Render の接続情報（DATABASE_URL）へリストア

pg_restore —verbose —no-owner —no-acl
-d “postgres://USER:PASS@HOST/DBNAME” latest.dump

あとは Render のダッシュボードで GitHub リポジトリを接続し、render.yaml を読み込ませてデプロイします。動作確認後に独自ドメインの DNS を Render に向け替え、Heroku 側は最後に停止します。 Railway なら railway up、Fly.io なら fly launch（fly.toml 自動生成）→ fly deploy が起点になります。 Render が向く: Heroku からの移行コストを最小化したいチーム、Web＋DB＋cron をまとめて管理したい小〜中規模、render.yaml で構成をコード化したい場合。 Railway が向く: プロトタイプや個人開発で素早く立ち上げたいケース、GitHub 連携で�ザクっと動かしたいチーム。 Fly.io が向く: Docker 運用が前提のチーム、複数リージョンでの低レイテンシ配信や常時稼働ワークロード。 避けるべきケース: 厳密なコンプライアンス要件や特定リージョン固定が必須の場合は、各社の対応状況を契約前に確認。無料枠の永続性に依存した本番運用は、条件変更リスクがあるため非推奨。 共通の注意: 料金は使用リソースで変動するため、本番移行前に小さく動かして実コストを計測してから判断してください。