Heroku alternatives: 安全な選び方と移行方法

Heroku alternative を選ぶなら、まずアプリが実際に使っているプロセスとアドオンから始めてください。 Lizard、Railway、Render は、web process、個別の worker、データベースの候補です。Cloud Run は異なるリソースモデルに適しています。VPS はより大きな制御を提供しますが、サーバー運用は引き続き自分で行う必要があります。

Heroku も依然として選択肢です。 sustaining engineering への移行は、既存のアプリケーションが直ちに離れる必要があることを意味しません。この Lizard 比較では、2026年9月9日時点のリンク先ソースを確認しています。

Heroku で何が変わったのか

2026年2月6日、Heroku は新機能よりも安定性、セキュリティ、信頼性、サポートに注力すると発表しました。通知では、新規を含むクレジットカード利用顧客は引き続き製品を利用できるとされています。一般的なサービス終了は発表されていません。Heroku の声明を読む。

移行の判断は、具体的な要件に基づくべきです。たとえば、コスト、必要な機能、デプロイ制約、または製品の方向性に対する見方です。サービスが終了するという根拠のない主張は、計画に役立たないまま緊急性だけを生みます。

ホストを比較する前に Heroku アプリを整理する

最小の web-instance 価格だけで選ぶ前に、この棚卸しを行ってください。worker、データベース、アドオンが、どの選択肢が実用的かを左右することがよくあります。

最も近い運用モデルを比較する

Lizard: 月額サブスクリプションやサービスごとのプラン料金なしで、web services と workers を使いたいなら選んでください。購入したクレジットに有効期限はありません。これは、小規模アプリや月の中で変動するワークロードに適しています。Managed Postgres と Managed Redis をリソース料金で追加し、Lizard CLI で操作できます。小規模アプリ計算 は、利用量が有料インスタンスの最低ラインを下回る可能性を示しています。接続変数は明示的に設定してください。

Railway: アプリの複数の構成要素をまとめて管理したいなら、その project と service のワークフローを評価してください。Railway は消費量を計測します。有料プランには使用量に充当されるクレジットが含まれます。これは dyno の固定価格の複製ではありません。Railway billing。

Render: 選択した容量のほうがチームにとって予算化しやすい場合は、その web と worker のインスタンスプランを評価してください。データベースと、必要な workspace 要件の価格も見積もってください。Render pricing。

Cloud Run: 各プロセスが サービス、Job、worker pool のどれに属するかを特定してください。Procfile をそのままコピーしても、Cloud Run のアーキテクチャは定義されません。Cloud Run リソース タイプ。

Coolify または別のデプロイツールを使う VPS: ホストを制御したく、かつ保守できる場合に検討してください。デプロイ用インターフェースがあっても、patching、ストレージの耐久性、disaster recovery まで引き継いでくれるわけではありません。Django VPS guide は、サーバーベースの構成に含まれる作業を示しています。

他の選択肢については、PaaS comparison を使ってください。

月額請求の全体を比較する

Heroku が公開している Cedar 料金では、Basic は $7/month、Standard-1X は $25/month です。これらは dyno の価格であり、web アプリ、worker、データベースを合わせた見積もりではありません。アプリが使っている foundation と plan を確認してください。Heroku pricing。

どの移行先でも、すべてのプロセス、データベース、保持されるファイル、ネットワーク料金、必要なプラン機能を含めてください。従量制プランでは、消費量を測定し、そのクレジットを織り込んでください。固定インスタンスでは、課金対象となるすべてのインスタンス数と稼働時間を数えてください。

比較では同じワークロードを維持してください。実行せずに、移行先で CPU やメモリ使用量が一部で済むと想定しないでください。また、移行中に旧システムと新システムが並行稼働する期間も含めてください。

トラフィックを切り替える前に複製を移す

1. シークレット値を公開ドキュメントに置かずに、設定の棚卸しをエクスポートします。ランタイムと依存関係のバージョンを固定します。
2. web process と worker を個別のテストサービスとしてデプロイします。start command と shutdown 動作を確認します。
3. データベースバックアップをテスト用データベースに restore します。PostgreSQL extensions、row counts、アプリケーションレベルの読み書きを確認します。
4. ログイン、メール、uploads、テストモードの payments、background jobs をテストします。callback domains と webhook URLs を確認します。
5. cutover 中の書き込みをどう扱うか決めます。maintenance window のほうが、書き込み可能な複製を 2 つ持つより判断しやすいことがよくあります。
6. 最終バックアップを取得するか replication を完了し、アプリケーション接続を切り替えてからトラフィックを変更します。errors、jobs、データベースアクティビティを監視します。

切り替え後に書き込まれたデータを含む rollback plan を維持してください。DNS を戻しても、それらの書き込みが旧データベースに移るわけではありません。

Lizard では、GitHub デプロイガイド と variable references から始めてください。worker settings は web service settings とは別に読んでください。

残ることが合理的な場合

アプリが要件を満たしており、チームがその運用モデルを理解していて、移行によって他に充てるべき時間が消費されるなら、Heroku に残ることが低リスクな選択になる場合があります。成熟したアプリは、アドオン、release steps、内部運用に依存していることがあり、そうした点はどんな機能比較表でも捉えきれません。

新しいホストに求める変更点を書き出してください。trial でそれが実証されないなら、その移行はまだコストに見合っていません。

FAQ

Heroku は終了するのですか？ 引用した発表ではそう述べていません。そこでは、sustaining engineering と、クレジットカード利用顧客への継続サービスが説明されています。これをサービス終了の期限として扱うのではなく、現在の声明と契約を評価してください。

Procfile はそのまま使えますか？ これは process commands の有用な棚卸しです。選んだホストがどのエントリを自動検出するかを確認し、それ以外は個別の services または jobs として設定してください。

Heroku Postgres を別の PostgreSQL サービスに移せますか？ 多くの場合は可能ですが、version、extensions、roles、restore process をテストしてください。本番トラフィックを切り替える前に、復元したデータでアプリケーションが動作しなければなりません。

移行でコストは下がりますか？ それを判断できるのは、完全な見積もりと代表的な trial だけです。データベース、workers、ストレージ、トラフィック、ホスト間の一時的な重複期間を含めてください。