2026.09.08 インフラ・クラウド

Railwayのデプロイ手順とrailway.ts移行｜料金の実額とリージョンの制約

Q: Railway CLIのインストールはどう行いますか？

npm・Homebrew・Scoopのいずれかです。npmなら npm i -g @railway/cli 、macOSのHomebrewなら brew install railway 、WindowsのScoopなら scoop install railway で入ります。導入後は railway login でブラウザ認証し、ブラウザを開けない環境では railway login --browserless を使います。以降の初回デプロイは railway init と railway up の2コマンドです。

Railwayのデプロイ手順とrailway.ts移行｜料金の実額とリージョンの制約

Railwayの日本語記事はほぼ全部がrailway.tomlで設定を書く前提になっていますが、公式ドキュメントはすでにその方式を非推奨とし、2026年12月1日を期限に.railway/railway.tsへ寄せています。この記事ではCLIでの初回デプロイをドメイン発行まで通したうえで、新方式への移行手順、秒単位課金を月額に落とした実額、アジアがシンガポール1拠点しかない制約を扱います。数値と仕様はすべて2026年9月8日時点の公式ドキュメントの記載です。PaaSそのものの管理範囲はIaaS・PaaS・SaaSの違いとは？管理範囲と選び方を比較表で解説で整理しています。

まとめ｜Railwayで最初に決める4項目と月額の目安

先に結論を出します。Railwayを触る前に決めるのは、①設定を新方式の.railway/railway.tsで書くか画面操作で済ませるか、②ビルドをRailpack任せにするかDockerfileを持つか、③リージョン（アジアならシンガポール）、④プラン（Free・Hobby・Pro）の4つです。

費用の桁も先に示します。CPUは1 vCPUあたり月20 USD、メモリは1 GBあたり月10 USD、ボリュームは1 GBあたり月0.15 USD、外向き通信は1 GBあたり0.05 USD。0.5 vCPU・512 MBのAPIを常時1本動かすと月15 USD前後で、PostgreSQLを1台足すと合計25 USD前後になります。

そして期限の話。railway.jsonとrailway.tomlは2026年12月1日で打ち切られます。これから書くなら旧形式に手を付けない判断が要ります。

PaaSとしてのRailwayが引き受ける範囲と秒単位課金の構造

Railwayはコードを置くとイメージを組み、コンテナを起動し、ログとメトリクスまで面倒を見るタイプのPaaSです。VMやKubernetesのノード管理は表に出てきません。同じPaaS層の選択肢はPaaSの代表例｜主要サービス一覧と選び方を提供事業者別に比較に一覧があります。

Railwayが自動で受け持つビルド・デプロイ・監視の担当範囲

公式のクイックスタートでは、GitHubリポジトリ連携・CLI・Dockerイメージ指定・テンプレート展開の4方式が案内されています。どれを選んでもビルドとコンテナ起動、ログ収集、メトリクス表示はプラットフォーム側の担当です。

PostgreSQL・MySQL・Redis・MongoDBはサービスとして追加でき、オブジェクトストレージ用のバケットも同じ画面から作れます。ここが自前でのインフラ構築と分かれる点で、DBの起動とバックアップ用ボリュームの確保に工数を割かずに済みます。

逆にプラットフォームが持たないものも明確です。ネットワークのACL設計、OSレイヤの調整、複数リージョンへの能動的な振り分けは範囲外になります。

プロジェクトとサービスの階層構造とプラン別レプリカ上限の実数

構造はプロジェクト＞環境＞サービスの3階層です。1つのプロジェクトにAPI・ワーカー・DBをサービスとして並べ、本番とステージングを環境で分けます。プラン別のリソース上限は1サービス単位で決まっています。

項目	Free	Hobby	Pro
月額	0 USD	5 USD	20 USD
含むクレジット	1 USD/月	5 USD	20 USD
vCPU上限	1	48	1,000
RAM上限	0.5 GB	48 GB	1 TB
レプリカ数	1	6	42
ボリューム	0.5 GB	5 GB	1 TB

実務で引っかかるのはレプリカ上限よりボリューム上限です。Hobbyの5 GBはPostgreSQLのデータ量が育つと足りなくなり、増やすにはProへ上げる必要があります。ログ保持もFreeは3日しかありません。

秒単位課金の内訳とFreeプランの月1ドル分で動く構成の範囲

課金はプラン料金に上乗せする従量制で、料金ページではCPUが1 vCPU秒あたり0.00000772 USD、メモリが1 GB秒あたり0.00000386 USDと秒単位で提示されています。月額換算で1 vCPU＝20 USD、1 GB＝10 USDです。停止中のサービスには課金されません。

Freeプランの月1 USDは、この単価で割ると0.05 vCPU・0.1 GB相当を1か月動かせる程度です。常時稼働のAPIには届きません。初回のみ30日有効の5 USDクレジットが付くので、検証はその枠で回すことになります。

秒課金の効き方には癖があります。1日1回だけ数分動くバッチなら、同じ0.5 vCPUの割り当てでも実質の課金は数十円で収まります。逆に常時起動のプロセスは割り当てた分をそのまま月額で払う形です。

Railway CLIで初回デプロイを通す手順と公開ドメインの発行

画面操作でも動きますが、再現性を残すならCLIを主にします。CLIのドキュメントにはnpm・Homebrew・Scoopの3経路が載っており、npm経由なら@railway/cliを入れます。

railway initからupまでのCLI操作と実行結果の確認箇所

最短の流れは次の5コマンドです。プロジェクトのルートで実行します。

npm i -g @railway/cli
railway login
railway init
railway up
railway domain

railway initが新規プロジェクトを作り、railway upがローカルのコードを送ってビルドを開始します。ビルドログだけを見たいときはrailway logs --build、実行中コンテナに入るならrailway sshです。環境変数はrailway variable set KEY=valueで入れます。

railway domainを引数なしで叩くと、Railway側のサブドメインが払い出されます。独自ドメインを充てる場合はrailway domain example.comの形です。ローカルで本番の環境変数を借りて動かすrailway run npm startも用意されています。

GitHub連携とDockerイメージ指定の3方式の使い分け基準

GitHub連携はpushで自動デプロイが走るため、継続的に更新するアプリの既定解になります。CLIのrailway upは手元から直接送るので、CIを組む前の検証や、リポジトリに載せられない構成の投入に向きます。

Dockerイメージ指定は、ビルド済みイメージをレジストリから引くだけの構成です。空プロジェクトにサービスを追加し、イメージ名を入れてデプロイします。ビルド環境をRailwayに依存させたくない場合はこれを選びます。

判断はシンプルです。アプリのソースがGitHubにあるならGitHub連携、それ以外はDockerイメージ。CLIは常用ではなく、初期構築と緊急時の手段に置きます。

railway.tsへの移行手順と2026年12月1日の設定ファイル期限

ここが既存の日本語記事と食い違う部分です。設定ファイルの方式が切り替わり、旧方式には期限が付きました。

非推奨になったrailway.jsonとrailway.tomlの扱い

Config as Codeのページには「Config as Code is deprecated」と明示され、既存のrailway.jsonとrailway.tomlが動作するのは2026年12月1日までのハードカットオフだと書かれています。推奨先はInfrastructure as Codeの.railway/railway.tsです。

旧形式のキーはbuild.builder、build.buildCommand、deploy.startCommand、deploy.healthcheckPath、deploy.restartPolicyTypeなどで、railway.schema.jsonがスキーマを公開しています。既存プロジェクトを引き継ぐときの読み解きには依然として要ります。

新規で書くなら旧形式に触らない判断です。2026年12月1日以降は読まれなくなるファイルを、これから増やす理由がありません。

defineRailwayで書く最小構成とconfig applyの適用

Infrastructure as Codeでは、railwayパッケージを入れて.railway/railway.tsを書きます。ビルドコマンドと起動コマンド、ヘルスチェックパスを持つ最小構成は次の形です。

import { defineRailway, project, service } from "railway/iac";

export default defineRailway(() => {
  const web = service("web", {
    build: "pnpm build",
    start: "pnpm start",
    healthcheck: "/health",
  });

  return project("my-app", { resources: [web] });
});

適用はrailway config planで差分を確認してからrailway config applyです。CIから流すときはrailway config apply --yesで対話を省けます。差分を見るステップが挟まるので、本番構成の取り違えに気付ける作りになっています。

config pullで既存プロジェクトを取り込む移行の順序

すでに画面や旧ファイルで組んだプロジェクトがある場合は、現状をコードに落としてから書き換えます。手順は次の4段です。

railway config pull --forceで既存構成を.railway/railway.tsへ取り込む
旧ファイルのキーを新APIの引数に置き換える（buildCommandはbuild、startCommandはstart、healthcheckPathはhealthcheck）
railway.jsonとrailway.tomlをリポジトリから削除する
railway config planで差分ゼロを確認しrailway config applyで確定する

npm install railway
railway config pull --force
railway config plan
railway config apply --yes

順序を守る理由は、旧ファイルを残したまま新方式を適用すると、どちらが効いているか判別しづらくなる点にあります。削除を移行の一工程として扱ってください。

Railpackによるゼロ設定ビルドとDockerfileを選ぶ判断点

Railwayの既定ビルダーはRailpackです。Dockerfileを置かなくてもイメージができるのは、この仕組みが言語とフレームワークを推定しているからです。

Railpackが言語を判定する仕組みとBuildKitとの関係

Railpackは自身を「コードを解析してイメージを作るゼロコンフィグのアプリケーションビルダー」と説明し、BuildKit LLBを使ってイメージを組むカスタムフロントエンドとして動きます。対応はNode・Python・Go・PHP・Java・Rubyほかで、Vite・Astro・Next.js・CRAの静的サイトも一次サポートに入っています。ソースもGitHubで公開済みです。

言語の推定はロックファイルや設定ファイルの存在で行われます。同種の考え方はCloud Native Buildpacksとは？Dockerfile不要のイメージ生成とリベース運用を実装目線で解説で扱ったビルドパックと重なりますが、Railpackは仕様としてのBuildpack v3準拠ではなくBuildKitフロントエンドという点が違います。

Dockerfileへ切り替える判断基準とビルド設定の指定方法

Railpackで足りるのは、標準的な依存解決とビルドコマンドで完結するアプリです。切り替えの線引きははっきりしています。OSパッケージを入れる必要がある、複数バイナリを1イメージに同梱する、ビルド段と実行段でベースイメージを分ける、このいずれかに当たるならDockerfileを置きます。

ビルドコマンドを明示したい場合は、新方式ならservice()のbuild引数、旧方式ならbuild.buildCommandです。Dockerfileがリポジトリのルートにあれば、Railpackではなくそれが使われます。

推定に任せた結果を放置しないでください。ビルドログでどのプロバイダが選ばれたかを確認し、意図と違えばDockerfileで固定するほうが後の事故が減ります。

ボリューム・内部通信・リージョン選択で詰まる構成面の制約事項

アプリを載せる分には数分で終わりますが、本番前提で見ると効いてくる制約があります。順に潰します。

ボリュームのマウント指定と自動注入される2つの環境変数の用途

ボリュームのガイドによると、指定したマウントパスはサービス内で読み書きできるディレクトリとして現れます。相対パスなら/appを含めた形でのマウントが必要です。接続するとRAILWAY_VOLUME_NAMEとRAILWAY_VOLUME_MOUNT_PATHが自動で入るので、アプリ側はパスをハードコードせずこの変数を読む書き方にできます。

容量の拡張はHobbyとProで稼働中に行えます。逆にFreeでは0.5 GBが天井で、ライブリサイズも使えません。アップロード画像やSQLiteを置く構成なら、この差でプランが決まります。

4リージョンの選択肢と日本からのレイテンシ設計における前提条件

デプロイリージョンの一覧は4つです。US West Metal（カリフォルニア・us-west2）、US East Metal（バージニア・us-east4-eqdc4a）、EU West Metal（アムステルダム・europe-west4-drams3a）、Southeast Asia Metal（シンガポール・asia-southeast1-eqsg3a）。日本リージョンはありません。

したがって国内ユーザー向けサービスの最短はシンガポールで、東京リージョンを持つクラウドと比べれば往復の遅延が上乗せされます。APIを1回叩いて画面が出るような用途なら実用範囲ですが、1画面で数十回の同期リクエストを積む設計だと体感に出ます。DBとアプリを別リージョンに置く構成は避けてください。

月額の実額計算とHeroku・Cloud Runとの費用差の見積り方

単価がわかれば見積りは電卓で済みます。プラン料金に従量分を足す構造なので、割り当てるvCPUとメモリを決めた時点で月額はほぼ確定します。

1サービス月額の試算とHerokuのdyno料金との実額比較

Node製APIを0.5 vCPU・512 MBで常時1本動かす場合、CPUが0.5×20＝10 USD、メモリが0.5×10＝5 USDで月15 USDです。Hobbyなら5 USDのクレジットが充当されるため、支払いはプラン料金5 USDと超過10 USDの合計15 USDになります。

PostgreSQLを0.25 vCPU・512 MB・ボリューム5 GBで足すと、5＋5＋0.75＝10.75 USD。API込みで月25.75 USD前後という桁感です。外向き通信は1 GBあたり0.05 USDなので、月100 GB出しても5 USDの追加で収まります。

dynoという固定サイズの箱で買うHerokuとは、そもそも課金の単位が違います。Railwayは割り当てたリソース×時間で、停止中は0です。Heroku側の体系はHerokuとは？料金・使い方・デプロイ手順をわかりやすく解説にまとめてあるので、移行検討ならプラン単価を突き合わせて比べてください。

クレジット超過時の停止挙動と使用上限を設定して事故を防ぐ手順

Freeとトライアルは、クレジットを使い切ると新しいデプロイが通らなくなります。有料プランは超過分が請求に回るため、放置した検証用サービスが月末に効いてきます。

対策は2つだけです。使い終わった環境はサービスを削除するか停止する（停止中は課金されません）。そしてワークスペースの使用上限を設定し、想定額を超えたら止まるようにしておく。ゼロスケールで待機コストを消す発想が要るなら、リクエスト単位課金のCloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを実装者目線で解説のほうが構造的に合います。

Railwayの採用を見送るべき本番要件と自前構築が安くなる場面

ここは判断を書きます。Railwayは万能ではなく、向く規模と向かない要件がはっきり分かれます。

Railwayを選ぶ根拠になる規模・体制・運用期間の3つの条件

採用してよいのは次の3つが揃うときです。第1に、サービス数が10前後まででレプリカも1桁に収まる規模。第2に、インフラ専任がおらずアプリ開発者がそのまま運用を兼ねる体制。第3に、社内ツールやMVPのように数か月〜1年程度の運用期間で、途中の作り替えを許容できる案件。

この条件下では、VPCとロードバランサとCI/CDを組む数十時間が消えます。月25 USD前後で本番相当が立つ意味は、金額よりも構築工数の削減にあります。変更履歴の更新頻度も高く、機能追加が速いプラットフォームです。

Railwayの採用を見送るべき本番要件と自前インフラに移す場面

見送る条件を具体的に挙げます。国内ユーザー向けで往復遅延が業務に直結するシステム、閉域網やIP固定を求められる案件、監査でリージョン所在を国内に限定される案件。この3つはリージョンが4つしかない時点で要件を満たせません。日本にリージョンがないという事実を、後から回避する手段はありません。

もう一つは費用の転換点です。常時8 vCPU・16 GBを回す規模になると、Railwayの単価では月320 USDを超えます。同等のVMを自前で確保したほうが安く、その水準ではインフラ構成を作り込む価値が出ます。要件が固まった本番システムを長期運用する段階に入ったら、インフラ構築（AWS・Google Cloud・Azure）のように東京リージョンで組み直す前提で設計してください。

逆に「まずは動かして反応を見る」段階でAWSのフル構成を作るのは過剰です。Railwayで立ててから移す、という順序のほうが投資の無駄が少なくなります。

よくある質問

Railwayの導入検討で検索されている質問に、公式ドキュメントの記載をもとに答えます。

Railwayは無料で使い続けられますか？

完全無料の常時稼働は現実的ではありません。Freeプランは月額0 USDですが、含まれるのは月1 USD分のクレジットで、1サービスあたり1 vCPU・0.5 GB、レプリカ1、ログ保持3日という制限が付きます。初回に30日有効の5 USDクレジットが付くため検証はここで足りますが、0.5 vCPU・512 MBのAPIを常時動かすと月15 USD相当かかるため、実運用ではHobby以上が前提になります。

railway.tomlはいつまで使えますか？

公式ドキュメントには、すでに使っているサービスに限り2026年12月1日までは動作すると明記されています。これがハードカットオフで、以降は読まれません。新規プロジェクトでは.railway/railway.tsを使い、既存プロジェクトはrailway config pull --forceで取り込んでからキーを置き換え、旧ファイルを削除する移行が要ります。移行後はrailway config planで差分が出ないことを確認してください。

Railwayに日本のリージョンはありますか？

ありません。選べるのはカリフォルニア、バージニア、アムステルダム、シンガポールの4拠点で、アジア太平洋はシンガポール（asia-southeast1-eqsg3a）だけです。国内向けサービスならシンガポールが最短ですが、東京リージョンを持つクラウドと比べると往復遅延が乗ります。1画面で同期リクエストを多数積む設計や、データの国内所在が要件になる案件では採用を見送る判断になります。

HerokuからRailwayへ移行する価値はありますか？

課金単位が変わる点が最大の違いです。Railwayは割り当てたvCPUとメモリの秒単位課金で、停止中は課金されません。固定サイズのdynoを買う体系より、小さいサービスを複数並べる構成では読みやすくなります。一方でリージョンは4拠点のみなので、遅延要件があるなら移行しても解決しません。判断はコストではなくリージョンとレプリカ上限から入ってください。

Railway CLIのインストールはどう行いますか？

npm・Homebrew・Scoopのいずれかです。npmならnpm i -g @railway/cli、macOSのHomebrewならbrew install railway、WindowsのScoopならscoop install railwayで入ります。導入後はrailway loginでブラウザ認証し、ブラウザを開けない環境ではrailway login --browserlessを使います。以降の初回デプロイはrailway initとrailway upの2コマンドです。