Railwayの代替サービス比較：料金・運用の違いと移行手順【2026年】

Railwayの代替を検討する前に、2026年10月21日のRailwayの発表を確認しておきましょう。同社は、復号済みの内容の一部を含む顧客の環境変数に、権限のない第三者がアクセスした可能性を公表しました。発表では「調査中はすべてのデプロイを停止しています」と述べ、環境変数や認証情報のローテーションを推奨しています。Railwayの発表

Webサービス、Postgres、ワーカー、cronジョブを使う構成なら、Railwayの代替として最初に検討したいのはRenderです。デプロイをより細かく制御したいチームには、Northflankが有力な比較候補になります。 Fly.ioはインフラを意図どおりに設計したい場合、Coolifyはサーバー運用を引き受けられる場合に向いています。Netlifyは、フロントエンドとサーバーレス関数を切り出す用途に適しています。

まず行うべきことは、認証情報の発行元でのローテーションと、アクセスログの確認です。プラットフォームを移すかどうかは、それとは別に判断します。同じキーを新しい管理画面へ持ち込んでも、ローテーションにはなりません。また、移行先にデプロイを用意することと、今日中に本番トラフィックを切り替えることは別です。

以下の料金と機能は、2026年10月22日に各提供元の公開ページで確認したものです。冒頭の引用はRailwayが発表した内容を示しており、現在のデプロイ状況を示すものではありません。本記事では、アプリケーションの処理内容との適合性と移行の手間を比較します。安全性を推測して各社を順位付けするものではありません。

Railwayの代替サービスを一覧で比較

移行先は、アプリケーション全体を見て選びます。サービスはリクエストに応答できる状態を保つプロセス、ワーカーはバックグラウンドジョブを処理するプロセス、cronは決められた時刻に処理を起動する仕組みです。Postgresはリレーショナルデータを保持し、ボリュームは交換可能なアプリケーションコンテナの外にファイルを保存します。同じ管理画面に並んでいても、それぞれの役割は異なります。

表の最低料金は利用を始める際の目安であり、構成全体の見積もりではありません。フロントエンドが無料ならデータベースやワーカーも無料だと誤解しないよう、有料のコンピュート、無料サンドボックス、ソフトウェアライセンス、従量単価を区別しています。金額はすべて米ドルです。追加コンポーネントや使用量には別途料金がかかります。

処理内容とシークレットの欄は、各社が文書化している運用方式として読んでください。保存時に暗号化されていても、認証情報にアクセスできるアプリケーションコードによる利用は防げません。たとえばFly.ioは、デプロイ権限を持つ人なら実行時のシークレットを読み取るコードをデプロイできると、明確に注意を促しています。Fly.ioのシークレット

比較対象と順位の決め方

この順位は、データを保持し、バックグラウンド処理も行う既存の小規模サービスを想定しています。静的なランディングページ向けではありません。既存のプロセスを無理なく対応させられるか、Postgresを誰が運用するか、永続ファイルをどこに置くか、定期処理がどう動くか、認証情報が実行中のコードにどう渡るかを判断基準にしています。

比較の根拠は、各提供元が公開する機能と確認時点の料金です。本記事のために各プラットフォームへデプロイしたり、ベンチマークを実施したりはしていません。稼働率、性能、安全性について、宣伝文句からスコアを推定することもしていません。

開発環境やKubernetes基盤の管理を支援するプラットフォームも便利ですが、今回の読者には不要な抽象化の層が増える場合があります。そのため、アプリケーションを実行できる移行先を中心に選び、Netlifyは用途をフロントエンド側に絞った候補として加えました。共有ファイルシステム、特定のスケジューラー動作、データベース復旧の運用委託が必要なら、選ぶべき候補は変わります。

このアプリ構成に適したプラットフォームの順位

1. Render：まず移行をリハーサルしたいマネージド環境

Renderは、Webサービス、バックグラウンドワーカー、cronジョブ、マネージドPostgresを備えたアプリケーションプラットフォームです。今回想定するRailwayの構成を、そのまま対応させやすいのが特徴です。サブスクリプション用API、メール送信ワーカー、夜間の照合処理を運用している創業者なら、各プロセスの配置先が明確になります。リハーサルを始める前のアプリ再設計を減らせる一方、永続ディスクには制約があります。ディスク付きのサービスは複数インスタンスへスケールできず、ディスクを接続すると無停止デプロイもできません。インフラの細かなカスタマイズより、今のアプリ構成を保つことを重視するならRenderが候補です。 サービスの種類 · ディスクの制限

向いている人： 構成全体を、使い慣れた方式のマネージド環境へ移したい創業者。
強み： API、ワーカー、定期タスクに、それぞれ専用のサービスタイプがあります。
料金： 有料サービスは月額$7〜。データベース、ワーカー、cron、該当するワークスペース料金は別途必要です。確認時点の料金
無料での試用： 制限付きの無料コンピュートがあります。評価用のリソースとして扱ってください。

設定はサービス変数か環境グループに保存します。環境グループは設定を共有する仕組みで、APIとワーカーが同じデータベースアドレスを使う場合などに便利です。ディスクから読み込む前提の認証情報には、シークレットファイルも使えます。実行中のサービスからは平文ファイルとして利用できます。本番用シークレットをすべてのプロセスへ一括で渡すのではなく、各プロセスに必要な設定だけを与えます。環境変数とシークレット

小さなアプリでも、ディスクの制約は無視できません。ワーカーが生成したPDFを後からWebサービスが読む場合、ワーカーにディスクを接続しただけでは、そのファイルをWebサービスから参照できるようにはなりません。切り替え前に、受け渡し先をオブジェクトストレージへ移すか、ファイルをどのプロセスが管理するかを見直してください。従来と同じパス名を使えても、両方のプロセスからアクセスできる保証にはなりません。

Renderで最初のサービスを試す手順

1. 1

   プロセスの分け方を再現する

   アプリケーションのリポジトリまたはコンテナからWebサービスを作成し、別の起動コマンドでワーカーを作成します。定期タスクはcronジョブとして追加します。データ移行のリハーサルの準備が整うまでは、新しいワーカーと定期実行を本番に対して動かさないでください。

2. 2

   移行先に空のデータベースを用意する

   Render Postgresを作成し、RenderのRailway移行手順に沿って、リハーサル用のエクスポートを復元します。Railway内だけで使えるホスト名をコピーせず、移行先の接続文字列を設定してください。

3. 3

   新しい認証情報で一連の処理を確認する

   確認済みの設定一覧から変数を登録します。仮ドメインでログイン、データベースへの書き込み、キューに入れたタスクとその結果を確認し、外部サービスへの処理はテスト用アカウントへ向けます。

プラットフォーム固有の手順は、RenderのRailway移行ガイドにあります。後半の切り替えチェックリストでは、デプロイが成功しただけでは確認できない、データと定期処理の移行まで扱います。

2. Northflank：デプロイの制御を重視するチーム向け

Northflankは、アプリケーションサービス、データベースアドオン、定期ジョブ、永続ストレージを備えたコンテナプラットフォームです。API、キューを処理するワーカー、定期インポートを維持する小規模チームなら、デプロイと設定のルールを明確にしたまま、まとめて構成できます。同じシステムにステージング環境と本番環境が必要になると、テンプレートやパイプラインが役立ちます。ただし、移行時に覚える管理項目は増えます。移行を機に複数サービスの運用も改善したいなら、Northflankが適しています。 プラットフォームの機能

向いている人： デプロイ定義を再利用し、各環境をより細かく管理したいチーム。
強み： サービス、ジョブ、データベース、ボリュームを備え、自分たちのクラウド環境へのデプロイにも進めます。
料金： 無料のSandboxがあります。有料CPUは**$0.01667/vCPU-hour〜**で、RAM、ストレージ、ネットワークは別途課金です。確認時点の料金
無料での試用： Sandboxは、リソース枠に制限のある無料プランです。

シークレットグループには、ビルド引数、実行時の変数、連携したデータベースの認証情報を保存できます。確認済みの変数を取り込み、利用先を必要なサービスや環境に限定し、依存サービスの再起動操作で変更を反映します。APIとワーカーは同じデータベース認証情報を使う一方、フロントエンドには不要、といった構成で役立ちます。シークレットグループ

自動移行で特に注意したい仕様があります。APIやCLIからシークレットグループを更新すると、PATCHリクエストであっても、送信対象の変数またはファイルのコレクションが置き換わります。変更したキーだけを送るスクリプトでは、残りが削除される可能性があります。既存のグループを読み込み、変更をマージしてから、文書化された手順でコレクション全体を送信してください。

料金は合計で判断する必要があります。CPU単価がそのままアプリの月額料金になるわけではなく、メモリ、永続ストレージ、外向きの通信量も加わります。処理構成の一覧をもとに、常時稼働するコンポーネントをすべて見積もり、運用制御の利点が追加の設定作業に見合うか判断します。

3. Fly.io：実行環境とリージョンを自分で選びたい場合に

Fly.ioは、処理内容に合わせて設定する軽量仮想マシン、Machine上でアプリケーションを動かします。APIとワーカーの配置先を自分で決めたい、デプロイの細部まで管理できる技術系の創業者に向いています。プロセスグループや別々のアプリを使えば、Webプロセスとワーカーを独立して動かせます。別アプリ間はFly.ioのプライベートネットワークで通信できます。ただし、定期実行や状態を持つデータの配置は、自分で設計する必要があります。最小構成の安さだけでなく、実際に使う制御機能を理由にFly.ioを選んでください。 プロセスの設定

向いている人： Machine、リージョン、プロセスの明示的な設定を扱える技術担当者。
強み： アプリごとの配置と実行環境を柔軟に設定できます。
料金： AshburnまたはSecaucusでは、RAM 256 MBの最小の常時稼働Machineが30日あたり$2.19です。マネージドPostgres、ストレージ、通信量は別料金です。確認時点の料金
無料での試用： 制限付きの試用枠があります。新規組織が継続して使える無料枠はありません。

文書化されている定期実行の選択肢には、タスクの実行時に一時的なMachineを起動するアプリのCron Managerや、コンテナ内でcronを動かすSupercronicがあります。便利な選択肢ですが、システムの一部としてデプロイし、運用しなければなりません。スケジューラーを誤って複数に増やし、それぞれが同じ請求リマインダーを送信する事態を避けてください。タスクの定期実行

Fly.ioはアプリのシークレットを暗号化された保管庫に保存し、Machine起動時に注入します。同じアプリのプロセスグループ間ではシークレットを共有しますが、別のアプリには個別の設定が必要です。必要な認証情報が異なるプロセスを別アプリに分ける理由になり、設定一覧に含めるべき作業にもなります。

リージョンを移す場合は、Webプロセスの配置先より先に、データベースの場所を決めます。APIがユーザーに近くても、リクエストのたびにデータベースとの間でリージョンを何度もまたぐなら、応答は遅くなり得ます。また、Fly.io Managed Postgresと、Machineとボリューム上で自分でデータベースを運用する構成は区別してください。後者で得られるのはサーバーであり、データベースの運用責任がマネージドサービスへ移るわけではありません。

4. DigitalOcean App Platform：DigitalOceanでステートレスなアプリを運用するなら

DigitalOcean App Platformは、Webサービス、ワーカー、ジョブを備えるマネージドのアプリケーションホスティングです。DigitalOcean Managed Databasesも併せて利用できます。アップロードファイルをすでにコンテナの外へ保存しており、アプリとデータベースを同じ提供元にまとめたい創業者に向いています。標準の定期ジョブも現在は文書化されているため、外部スケジューラーが必須とは限りません。決定的な制約はストレージで、App Platformはボリュームに対応していません。ローカルファイルシステムを一時領域として扱えるアプリなら候補になります。 App Platformの制限

向いている人： ステートレスなAPIとワーカーを運用する人。特に、すでにDigitalOceanを利用している場合。
強み： マネージドのアプリコンポーネントに、標準の定期ジョブを組み合わせられます。
料金： 有料コンテナは月額$5〜。データベース、他のコンテナ、追加の使用量は別料金です。確認時点の料金
無料での試用： 静的サイト向けの無料枠はありますが、今回のバックエンド構成全体をまかなうものではありません。

環境変数はアプリ単位またはコンポーネント単位で設定し、ビルド時か実行時かを指定できます。機密値にはEncryptオプションを使います。DigitalOceanの文書では、この設定によってビルド、デプロイ、アプリケーションのログから値を隠せると説明されています。フロントエンドのビルドでデータベースアクセスが必要でなければ、データベースのパスワードを渡さないでください。環境変数

スケジューラーの定期ジョブは、最短15分間隔で実行できます。夜間のレポートには問題なくても、より短い間隔で動くことを前提にしたタスクには、別の設計かプラットフォームが必要です。同等の移行ができたと判断する前に、実行スケジュール、タイムゾーン、観測された最長の実行時間を確認します。定期ジョブの設定

ファイル移行でよく使う方法は、ローカルのアップロードディレクトリをオブジェクトストレージへ置き換え、オブジェクトの識別子をPostgresに保存する構成です。アプリケーションの変更を伴うため、トラフィックを移す前に試してください。ディレクトリをコンテナイメージにコピーしても、その後ユーザーがアップロードするファイルは永続化されません。また、本番用のManaged Databaseは、アプリの料金ページに掲載されている開発用データベースとは分けて評価します。

5. Heroku：dynoの運用に慣れたチーム向け

Herokuは、Webプロセス、ワーカー、単発タスクを実行するコンテナ「dyno」を中心としたマネージドのアプリケーションプラットフォームです。このプロセスモデルをすでに理解していて、マネージドのHeroku Postgresを使いたいチームには実用的な移行先です。Webアプリとキュー処理を分けた一般的な構成を、無理なく対応させられます。注意点は、一時的なファイルシステムとHeroku Schedulerの動作です。慣れた運用方式を重視してHerokuを選ぶなら、ファイルと重要な定期処理の扱いを明確にしておきます。 dynoのドキュメント

向いている人： Herokuのデプロイ方法とプロセスの扱いに慣れたチーム。
強み： Web用・ワーカー用dynoとマネージドPostgresを組み合わせられます。
料金： 常時稼働のBasic dynoは月額$7〜。データベース、ワーカー、定期タスクのコンピュートは別料金です。確認時点の料金
無料での試用： 無料のバックエンド枠を前提に予算を組まないでください。ここで挙げた常時稼働の選択肢は有料です。

Herokuは設定を永続的なアプリ設定であるconfig varsに保存し、環境変数として公開します。config varを変更するとリリースが作成され、アプリケーションが再起動します。認証情報のローテーションはアプリの動作に影響する作業として計画し、新しい認証情報を検証し、再起動を確認したうえで、発行元で古い認証情報を削除します。config vars

Heroku Schedulerの文書では、ジョブは実行される想定であるものの、実行は保証されないと説明されています。重要な定期処理には、独自のクロックプロセスを推奨しています。キャッシュの削除が一度抜けることと、請求の照合が抜けることでは影響が異なります。後者には、確認可能な実行記録、リトライ、用途に合ったスケジューラーの選択が必要です。Schedulerの動作

Basic dynoは水平スケーリングにも対応していません。複数のインスタンスを並行稼働させるには、別のdynoプランが必要です。リハーサルには十分でも、アプリが起動するプランが本番トラフィックにも適しているとは限りません。dyno内に書き込んだファイルは停止や再起動で消えるため、保持すべきアップロードファイルは先に移してください。

6. Koyeb：本番用ボリュームに依存しないサービス向け

Koyebは、Webサービス、ワーカー、マネージドのサーバーレスPostgresに対応するアプリケーションプラットフォームです。APIとバックグラウンド処理が、すでにローカルの永続ファイルに依存していないなら検討する価値があります。アプリのソースコードとビルド済みコンテナのどちらも使えるため、デプロイのリハーサルを始めやすい構成です。一方、Railwayでボリュームを多用するアプリにとっての障害は、文書に明記されています。ボリュームはパブリックプレビューで、テスト用途にのみ適するとされています。Koyebはステートレスな部分の候補にし、本番ボリュームをそのまま置き換える先とは考えないでください。 サービスモデル · ボリュームの提供状況

向いている人： 永続データをすでにアプリのボリューム外へ保存している、Webサービスとワーカーの運用者。
強み： Webとワーカーのサービスタイプを分け、サーバーレスPostgresも利用できます。
料金： 公開されているProの基本料金は月額$29＋コンピュート料金で、$10分のコンピュートを含みます。構成全体の見積もりではありません。確認時点の料金
無料での試用： 個々のリソースに無料枠があっても、構成全体を無料で運用できるとは限りません。

Koyeb Secretsは組織単位の値で、サーバー側で暗号化され、指定したサービスに利用権限を付与します。サービスは環境変数を通じてSecretを参照できます。再利用によってデータベース設定を簡略化できますが、組織全体で利用できる仕組みだからこそ、どの値をどのサービスへ渡すかを慎重に決めます。Secretsのドキュメント

Koyebのサービスリファレンスでは、Webサービスとワーカーが定義されています。cronが必要なら、ワーカー内のスケジューラーか外部トリガーを計画し、リハーサルで検証してください。Railwayのスケジュールを自動的に引き継げるとも、本比較で同等の標準cronサービスを確認できたとも考えないでください。

予算にはProプランと、サービスおよびデータベースが消費するリソースを合わせて計上します。プランにコンピュート枠を含むため、他社の最小アプリコンテナとは料金の単位が違います。どちらが安いかを判断する前に、実際の処理構成に沿った見積もりを作ってください。

7. VPS上のCoolify：サーバー運用を引き受けられる場合に

Coolifyは、自分で管理するサーバー上でアプリケーションとデータベースを動かす、セルフホスト型のデプロイソフトウェアです。レンタルする仮想サーバーであるVPS上に、コンテナベースのWebサービス、ワーカー、Postgres、定期タスクを再現できます。各コンポーネントにマネージドのアプリケーションプラットフォームを使う必要はありません。実行環境の運用を引き受けられる技術系の創業者に向いています。ただし、運用責任は自分たちにあります。使いやすい管理画面からPostgresを動かしても、提供元が運用するマネージドデータベースにはなりません。サーバー保守、バックアップ、復旧の責任者を決められる場合に限って、Coolifyを選んでください。 Coolifyのドキュメント

向いている人： サーバーを自分で制御したい、保守作業も引き受けられる技術担当者。
強み： 自分のインフラ上で、アプリとデータベースのデプロイを管理できます。
料金： セルフホスト版ソフトウェアは無料ですが、VPSが別途必要です。一例として、DigitalOceanの4 GiB・2 vCPUサーバーは月額$24で、バックアップなどのサービスは別料金です。Coolifyの料金 · VPS料金
無料での試用： セルフホスト版のソフトウェアは無料ですが、サーバーは含まれません。

このサーバーは料金例であり、推奨スペックではありません。すべてを同じマシンに置くと、ビルド、データベース、ユーザーからのリクエストがリソースを奪い合います。メモリを多く使うビルドが、アプリの障害につながる可能性もあります。実際の負荷を測り、運用上の余裕を確保し、どのコンポーネントを別の場所へ置くか決めてください。

Coolifyでは、ビルド時と実行時の設定を使ってアプリの変数を管理します。バックアップの文書によると、保存した認証情報や秘密鍵は、インスタンスのAPP_KEYを使ってデータベース内に暗号化して保存されます。復元可能なインスタンスのバックアップに加え、このキーも別に保管してください。キーがないままデータベースだけを復元しても復旧できないと、障害時に初めて気づく事態は避けたいところです。インスタンスのバックアップと暗号化キー

定期タスクはアプリまたはサービスのコンテナ内でコマンドを実行するため、アプリとサーバーが動作していることに依存します。永続ストレージにはサーバーのボリュームやマウントを使います。便利な仕組みですが、アプリ、データベース、唯一のバックアップを同じVPSに置けば、すべてがそのサーバーに依存します。復旧に必要なものは独立した場所にも保管し、再構築をリハーサルしてください。定期タスク · 永続ストレージ

8. Netlify：フロントエンドとサーバーレス部分の移行先

Netlifyは、サーバーレス関数を備えたフロントエンドのデプロイプラットフォームです。常時稼働するバックエンドから、その部分を切り離せる場合に候補になります。たとえば、マーケティングサイトとフロントエンドを移し、APIとキューワーカーはRenderやNorthflankで動かす構成です。Netlifyは現在、Netlify Databaseを通じてマネージドPostgresも提供しています。「マネージドPostgresがない」とする説明は正確ではありません。なお残る違いは実行方式です。実行時間に上限のある関数は、常時稼働するサービスやキューを継続的に処理するプロセスにはなりません。Netlifyの関数モデルに合う部分を移す場合に選んでください。 Netlify Databaseのドキュメント

向いている人： 切り離したフロントエンドに、リクエスト駆動の関数や実行時間内に完了するバックグラウンド関数を組み合わせる人。
強み： フロントエンドのデプロイ、関数、統合されたマネージドPostgresを利用できます。
料金： 無料で始められ、Personalは**月額$9〜**です。使用量はクレジット制です。確認時点の料金
無料での試用： 無料プランがありますが、デプロイした処理にもその制限が適用されます。

Netlify Background Functionsには、15分の実行時間上限があります。非同期処理は可能ですが、無期限に動き続けるキュー処理の代わりにはできません。Scheduled Functionsはcron式で処理を起動できますが、やはり実行制限のある関数です。キューを継続的にポーリングするタスクには、別の実行環境を用意するか、時間内に完了する呼び出し単位へ意図的に再設計する必要があります。Background Functions · Scheduled Functions

機密値はリポジトリ内の設定に書かず、NetlifyのUI、CLI、APIから保存します。文書では、プラットフォームに保存する変数とnetlify.toml内の変数を区別しています。デプロイコンテキスト別の値にも対応し、プレビューでは別の認証情報を使えます。スコープの制御やシークレット関連の機能はプランによって異なります。また、ブラウザー向けJavaScriptに埋め込まれた値は、ビルド時にどこから読み込んだかにかかわらず、ブラウザーから参照できることにも注意してください。環境変数

Netlify Databaseでは、対応するワークフローの中でPostgresの作成、マイグレーション、ブランチ作成ができます。ただし、既存データベースの拡張機能、インポート要件、ワーカー構成がそのまま適合する保証にはなりません。Netlify Blobsはオブジェクトストレージであり、アプリに接続するファイルシステムではありません。分割によって移行リハーサルがアプリの書き直しになってしまうなら、最初は既存のバックエンドをまとめて維持してください。Blobsのドキュメント

移したい範囲がフロントエンドと関数なら、Netlifyを確認してください。

Railwayの代替は、結局どれを選ぶべきですか？

プロセスの分け方をできるだけ変えずにリハーサルするなら、まずRenderから始めます。 環境の再利用、パイプライン、将来の自社クラウドへの移行が重要な要件なら、Northflankも並べて比較してください。RailwayとRenderの違いに絞った比較は、RailwayとRenderの比較記事を参照してください。

Fly.ioは、実行環境やリージョンの制御が必要な理由を説明できる場合に選びます。DigitalOcean App Platformは、ローカルファイルを消えてよいものとして扱えて、定期実行の条件も合う場合に適しています。Herokuは、慣れた運用方式で移行の手間を減らせる場合の候補ですが、重要な定期処理についてはSchedulerの前提を見直し、必要な代替策を用意します。

Koyebは、現時点のボリュームに関する注意事項を守ったうえで、ステートレスな構成の候補に入れます。Coolifyは、運用担当者を決めて自分たちで管理する候補です。Netlifyはマネージドデータベースも提供していますが、候補にする主な範囲はフロントエンドとサーバーレス処理です。

判断を変える基準は明快です。必要な動作を維持するためにアプリの再設計が必要なら、そのホストは最小の手間で用意できる待機先ではありません。 長期的には適切な移行先でも、書き直しとリハーサルの費用を移行コストに含めて判断してください。

Railwayからの移行チェックリスト：リハーサルから本番切り替えまで

移行先の準備が整ったと言えるのは、データを復元でき、アプリの重要な処理を完了できるようになったときです。デプロイ成功は最初の確認点にすぎません。完全移行を予定している場合も、後から切り替えられる待機先を用意する場合も、同じチェックリストを使います。

1. 1

   稼働中のシステムを棚卸しする

   各サービスのソースのリビジョンまたはイメージ、ビルドコマンドと起動コマンド、ランタイムのバージョン、ヘルスチェック、必要なリソース、リージョン、依存先を記録します。Postgresのデータベース、拡張機能、ロール、永続ディレクトリ、キューやキャッシュのサービス、送信元IPの許可リスト、ドメイン、すべての定期タスクとタイムゾーンを洗い出します。各項目に担当者を割り当ててください。

   ワーカーが何を処理し、ジョブの状態がどこに保存されるかも記録します。「Web、Postgres、ワーカー、cron」という構成でも、キューサービス、ファイル用バケット、メール配信サービスに依存している場合があります。それらを移さなくても、移行先からアクセスできる必要があります。

2. 2

   設定をエクスポートし、発行元で認証情報を更新する

   環境変数を、アクセスを制限した一時的な一覧へエクスポートします。機密ではない設定と、データベース認証情報、APIキー、レジストリ認証情報、署名用シークレット、提供元が生成するアドレスを分けます。各値を使うプロセスと、ビルド時に必要なのか実行時だけなのかを記録します。エクスポートした内容を、ソース管理、チケット、チャットへ載せないでください。

   発行元で、必要な権限とスコープを持つ代替の認証情報を作成します。移行先と、継続稼働が必要な移行元の処理に設定してください。アクセスを検証し、古い認証情報を速やかに失効させ、提供元のログを確認します。インシデント固有の失効手順でさらに迅速な対応が求められる場合は、それに従います。認証情報の悪用を防ぐ対応を、プラットフォーム移行まで待たせてはいけません。

   データベースのパスワード、Webhookの署名キー、データ暗号化キーでは、ローテーションの手順が異なります。既存データを復号する手段を残さずに暗号化キーを置き換えると、アプリが動かなくなる可能性があります。Railway外の利用先も含め、認証情報ごとに手順を管理してください。キーをコピーするのはエクスポートであり、古いキーを使えなくするのがローテーションです。

3. 3

   Postgresのダンプと復元をリハーサルする

   移行先に空のデータベースを作ります。データを移す前に、対応する拡張機能、照合順序、エンコーディング、ロール、権限を確認します。互換性のあるpg_dumpクライアントで取得したカスタム形式のアーカイブをpg_restoreで復元するか、移行先がサポートするインポート手順に従ってください。RenderのRailway移行ガイドには、移行先での具体的な手順があります。

   論理ダンプはある時点のデータベースのスナップショットであり、継続的なレプリケーションではありません。リハーサル用のデータを復元し、復元エラーを調べ、各テーブルの件数と代表的な業務レコードを比較し、シーケンスの値を確認して、アプリのマイグレーションを計画どおりに実行します。移行先の認証情報で読み書きをテストしてください。ロール、権限付与、その他のクラスターレベルの設定は、別途確認が必要です。

   最終転送では、サポートされたレプリケーション方式があり、最終同期もリハーサル済みである場合を除き、移行元の書き込み処理を停止するか遮断してから最終エクスポートを取ります。実測した復元時間を事業上許容できない場合は、切り替え日を決める前にレプリケーション方式を設計してください。早い段階で取得に成功したダンプに、その後の注文まで含まれていると考えてはいけません。

4. 4

   ボリュームを移し、ファイルの管理主体を明確にする

   各永続パスに何があるかを確認します。アップロード、生成ドキュメント、アプリの状態、データベースなどです。通常のファイルは移行先のストレージへコピーし、必要な所有者と権限を維持したうえで、件数、サイズ、チェックサムなどを検証します。書き込みを止めてから最終同期を行ってください。

   データベースには、サポートされているバックアップまたは移行手順を使います。稼働中のデータベースファイルを、通常のアップロードファイルのようにコピーしてはいけません。共有するアプリファイルは、読み取り側のすべてのプロセスが新しい場所へアクセスできることを確認します。移行先にボリュームがない場合、オブジェクトストレージへの変更はコードとストレージの移行であり、マウントパスを書き換えるだけでは済みません。

5. 5

   プライベートネットワークとドメイン設定を再構成する

   Railway内だけで使えるホスト名を、移行先の内部エンドポイントに置き換えます。Webサービス、ワーカー、定期タスクから、Postgresと各キューの名前解決と接続ができることを確認します。データベースのTLS設定を合わせ、必要に応じて外部提供元のIP許可リストを更新してください。以前の接続方式を維持するためだけに、プライベートなデータベースを公開してはいけません。

   リハーサルには移行先の仮ドメインを使います。カスタムドメインと証明書を用意し、OAuthのコールバック、Webhookの送信先、許可するオリジン、Cookieのドメイン、アプリのベースURLを確認します。切り替えに役立つ場合は、DNSのキャッシュ時間を事前に短くします。ただし、古いレコードを保持するリゾルバーもあることを見込んでください。

6. 6

   外部への影響を抑えて一連の動作を試す

   ログイン、書き込み、キューのタスク、定期タスク、結果として生成されるファイルや通知までを含むユーザー操作をテストします。決済とメールにはテスト用アカウントを使うか、外部への処理を無効にします。復元にかかった時間と、移行先の準備完了を判断できる確認項目を記録してください。

   移行元が処理を担っている間は、移行先のcronと本番キューの処理を動かさないでください。同じ請求書を送ったり、同じジョブを消費したりしている待機先は、すでに本番処理に参加しています。ジョブは安全に再試行できるようにし、重複実行を検知できるよう、完了記録を永続的に残します。

7. 7

   正とする書き込み先を一つに保ち、段階的に切り替える

   定期実行を一時停止し、キューの動作に応じてバックグラウンド処理を停止するか、処理中の仕事を完了させます。移行元への書き込みを遮断し、データベースの最終転送とファイル同期を終え、移行先を検証します。トラフィックを新しいアプリへ向けた後、ワーカーと定期実行を明示的に有効にしてください。

   アプリのエラー、データベース接続、キュー内ジョブの待ち時間、タスクの完了、外部への処理を監視します。移行元は書き込みを無効にした状態で、管理された復旧用の選択肢として残します。内容が分かれていくデータベースに対して、両環境を動かし続けないでください。

   切り替える前に、移行先が新しい書き込みを受け付けた後で障害が起きた場合の対応を決めます。DNSを戻して古いデータベースを使うと、新たな変更が稼働中のアプリから失われます。復旧には、移行先の修正、復元、新しいデータの移行元への転送が必要になる場合があります。本番トラフィックを受ける前に、この判断基準を定めてください。

データベースの手順は、PostgreSQLのダンプに関する文書とRenderのRailway移行ガイドに基づいています。ここで示した順序は運用上の推奨手順です。無停止を保証するものと受け取らず、自分のアプリで所要時間や動作を測ってください。

待機先として維持する場合は、構成一覧を最新に保ち、復元データにどの程度の新しさが必要かを決め、アプリやスキーマが変わったら再度リハーサルします。復元手順を検証していない古いデプロイは、リポジトリのコピーであって、すぐに使える代替環境ではありません。

今回の移行で避けたい選び方

常時稼働するキューワーカーを変更せずに移す先として、Netlifyを選ぶのは避けてください。 適合する部分だけ関数モデルを使うか、ワーカーをサービス実行型のプラットフォームに残します。マネージドPostgresの提供によって、関数の実行制限が変わるわけではありません。

文書でテスト専用とされている間は、今回の本番移行でKoyebのボリュームを使うのは避けてください。 外部データベースやオブジェクトストレージを使えばKoyebが適する場合もありますが、それはストレージ設計を変える選択です。

ローカルの永続ファイルに依存するアプリを、そのままDigitalOcean App PlatformやHerokuへ移すのは避けてください。 どちらの実行モデルも、Railwayのようなマウント済みボリュームとしてファイルを保持するものではありません。先にストレージへの依存を解消します。

サーバーの責任者がいないなら、Coolifyは避けてください。 ソフトウェアでデプロイを簡単にできても、担当が決まっていない運用責任までなくなるわけではありません。

最後に、広告にある最小リソースの料金だけで選ばないでください。APIが動いていても、データベース、キュー処理、定期実行がなければ、復旧させるべきシステムにはなりません。

Railwayの代替に関するよくある質問

Railwayの代替サービスは、どれがおすすめですか？

今回のWebサービス、Postgres、ワーカー、cronの構成では、まずRenderを評価し、Northflankも並べて検討します。実行環境を明示的に制御したいならFly.io、自分でサーバーを運用するならCoolify、フロントエンドと実行時間内に収まる関数ならNetlifyが適しています。必要なファイル保存方式や定期実行の動作によって、優先順位は変わります。

Railwayの代わりに無料で使えるサービスはありますか？

Northflankには制限付きの無料Sandboxがあり、RenderとNetlifyにも、それぞれ対象となる処理範囲が異なる無料枠があります。セルフホスト版のCoolifyは無料でも、サーバーは必要です。いずれも「無料」という表示だけで、本番の処理全体、バックアップ、運用上の要件をすべて無償で満たせるとは判断できません。

Railwayの代替となるオープンソースの選択肢はありますか？

この比較でセルフホストの選択肢となるのはCoolifyです。自分のVPSでコンテナとデータベースを動かし、パッチ適用、容量管理、復旧に責任を持てる場合に使います。デプロイの操作画面は置き換えやすくても、インフラを運用する人の代わりにはなりません。

RailwayとRenderはどう比較すればよいですか？

Renderを最初のリハーサル候補にする理由は、Web、ワーカー、cron、マネージドPostgresが、今回の構成に対応するからです。ただし、永続ディスクの制限は確認が必要です。実際に移行するかどうかとは別に、Railwayのインシデントに関する案内に従って認証情報をローテーションしてください。