Rails・Laravel本番デプロイ実践 ― VPSでフルスタックフレームワークを正しく公開する

RailsやLaravelは「開発は快適」だが，本番デプロイには独自の勘所がある．アセットのプリコンパイル，DBマイグレーション，ジョブキュー，環境変数── これらを正しく扱わないと，本番で思わぬ事故に遭う．

両者はフルスタックフレームワークとして共通点が多い．アプリケーションサーバー(Puma/PHP-FPM)＋Nginx＋DB＋ジョブキューという構成の理解が，安定デプロイの鍵になる．

この記事は，Rails/LaravelアプリをVPSで公開する個人開発者に向けている．サーバー構成，マイグレーション，アセット，ジョブ，常駐までを実践的に解説する．

読み終えたとき，あなたはフルスタックフレームワークを本番品質で安全に公開・運用できるようになっている．

なぜフルスタックの本番デプロイは勘所が多いのか

RailsやLaravelは「アプリのコードを動かす」だけでは本番にならない．アセット(CSS/JS)のビルド，DBスキーマの適用(マイグレーション)，バックグラウンドジョブ，スケジュール実行など，付随する要素が多い．

これらをデプロイのたびに正しい順序で実行しないと，「アセットが古い」「マイグレーション未適用でエラー」「ジョブが処理されない」といった事故が起きる．

また開発サーバー(rails server/php artisan serve)は本番用ではない．本番用のアプリケーションサーバー(Puma/PHP-FPM)＋前段のNginxという構成が必須だ(Pythonデプロイ記事と同じ考え方)．

これらの勘所を体系的に押さえることが，フルスタックアプリを安定して公開し続ける条件になる．

本番の構成 ― アプリケーションサーバーとNginx

RailsもLaravelも，前段にNginxを置き，背後でアプリケーションサーバーがアプリを動かす．RailsはPuma，Laravel(PHP)はPHP-FPMが標準だ．

	Rails	Laravel(PHP)
アプリサーバー	Puma	PHP-FPM
前段	Nginx	Nginx
アセット	precompile(Sprockets/jsbundling)	npm run build(Vite等)
ジョブ	Sidekiq/Solid Queue等	Queue worker

共通するのは，Nginxが静的配信とHTTPS終端を担い，アプリケーションサーバーが動的処理を担うこと．RailsならNginx → Puma，LaravelならNginx → PHP-FPMに振り分ける(リバースプロキシ記事参照)．開発サーバーは本番では使わない．

環境変数と秘密情報 ― 本番設定の分離

本番では環境変数で設定を切り替える．DBの接続情報・APIキー・アプリのシークレットキーをコードに含めず，環境変数や専用の仕組みで管理する．

本番環境変数の例

# Rails: RAILS_ENV=production と credentials/master.key
RAILS_ENV=production
SECRET_KEY_BASE=...
DATABASE_URL=postgres://app:pass@localhost/myapp

# Laravel: .env と APP_KEY
APP_ENV=production
APP_KEY=base64:...
APP_DEBUG=false        # 本番では必ずfalse

LaravelのAPP_DEBUG=falseは必須だ．trueのままだとエラー時に内部情報(設定・スタックトレース)が画面に晒される重大なリスクになる．Railsのmaster.keyやLaravelのAPP_KEYは暗号化の要であり，Gitに含めず安全に管理する(シークレット管理の記事参照)．

DBマイグレーション ― デプロイ時の適用

コードの更新時，DBスキーマの変更(マイグレーション)を適用する必要がある．これを忘れると「カラムが無い」等のエラーで本番が落ちる．

マイグレーションの適用

# Rails
RAILS_ENV=production bin/rails db:migrate

# Laravel
php artisan migrate --force   # 本番は--forceで確認プロンプトを省略

デプロイ手順にマイグレーションを必ず組み込む．重要なのは順序だ──通常は「コードを配置→マイグレーション→アプリ再起動」だが，破壊的なスキーマ変更(カラム削除等)は，旧コードが動いている間に実行すると不整合を起こす．本番のマイグレーションは慎重に，そして必ず事前にDBバックアップを取ってから行う(DB記事参照)．

アセットのプリコンパイル ― 本番用ビルド

CSS/JSは，本番では事前にビルド(プリコンパイル)しておく．これによりNginxが効率的に配信でき，毎リクエストでのビルドを避けられる．

アセットのビルド

# Rails
RAILS_ENV=production bin/rails assets:precompile

# Laravel(Vite等)
npm ci && npm run build

プリコンパイルされたアセットは，ファイル名にハッシュが付く(キャッシュ対策)．これをNginxで長期キャッシュ配信すれば高速だ(Nginxチューニング記事参照)．デプロイのたびにビルドを実行し，古いアセットが残らないようにする．CI/CDでビルドしてから配置するのも良い．

ジョブキューとスケジューラ ― 非同期処理の常駐

メール送信・重い処理・定期実行は，バックグラウンドジョブで処理する．これらのワーカーも，アプリ本体とは別に常駐させる必要がある．

ジョブワーカーの常駐(systemd)

# Rails(Sidekiq等)のワーカーをsystemdで常駐
# ExecStart=.../bundle exec sidekiq -e production

# Laravelのキューワーカー
# ExecStart=php artisan queue:work --tries=3
# スケジューラ(cron or systemd timer)
# * * * * * php artisan schedule:run

ジョブワーカーはアプリ本体とは別のsystemdサービスとして常駐させる(systemd記事参照)．Laravelのschedule:runは1分ごとに呼ぶ必要があり，cronまたはsystemd timerで仕込む(定期実行記事参照)．「Webは動くのにメールが送られない/定期処理が動かない」ときは，このワーカーの常駐忘れを疑う．

デプロイ手順をまとめる ― 順序が命

ここまでの要素を，正しい順序のデプロイ手順にまとめる．順序を誤ると本番が壊れる．

コードを取得(git pull / 新バイナリ配置)
依存をインストール(bundle install / composer install –no-dev)
アセットをビルド(precompile / npm run build)
DBバックアップ→マイグレーション(db:migrate / artisan migrate)
アプリとワーカーを再起動(Puma/PHP-FPM/ジョブワーカー)

この手順をスクリプト化しCI/CDに組み込むと，手作業のミスが消える(CI/CD記事参照)．そしてデプロイ前にスナップショットを取れば，マイグレーション失敗などの事故からも丸ごと戻せる．フルスタックのデプロイは要素が多いぶん，自動化と「戻せる」備えの価値が大きい．

補論：フルスタックの本番は「余裕のあるVPSと戻せる安心」で安定する

RailsやLaravelは，アプリ本体＋DB＋ジョブワーカー＋Nginxと複数のプロセスが同居する．そのため，メモリとCPUに余裕のあるVPSが安定の前提になる．そしてマイグレーションを伴うデプロイには「戻せる」備えが要る．

高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ はメモリをスケールアップで増やせ，NVMe SSDでアセットビルドやマイグレーションも高速だ．デプロイ前にスナップショットを取り，マイグレーションが失敗したら丸ごと戻す運用がしやすく，フルスタックの本番基盤として堅実だ．

公開には独自ドメイン＋HTTPSが要る．取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ でドメインを取得し，NginxでHTTPS終端してPuma/PHP-FPMに振り分ければ，本番品質のRails/Laravelサービスが完成する．

よくある質問(FAQ)

Q1．開発サーバーで公開してはダメ？

ダメだ．rails serverやphp artisan serveは開発用で本番の負荷に耐えない．Puma/PHP-FPMを使い，前段にNginxを置く(Pythonデプロイ記事と同じ考え方)．

Q2．マイグレーションで本番を壊さないコツは？

必ず事前にDBバックアップを取り，破壊的変更(カラム削除等)は段階的に行う．デプロイ手順に組み込み，CI/CDで自動化し，デプロイ前スナップショットで戻せるようにする．

Q3．Laravelで最初に確認すべき本番設定は？

APP_DEBUG=falseだ．trueだとエラー時に内部情報が晒される重大リスクになる．加えてAPP_KEYの安全な管理とAPP_ENV=productionを確認する．

Q4．メールやジョブが処理されない

ジョブワーカーの常駐忘れが定番だ．キューワーカー(Sidekiq/queue:work)をアプリとは別のsystemdサービスで常駐させる．Laravelのスケジューラはschedule:runをcron/timerで毎分呼ぶ必要がある．

Q5．アセットが古いまま表示される

デプロイ時にアセットのプリコンパイル/ビルドを実行しているか確認する．ハッシュ付きファイル名なので，ビルドし直せば新しいものが配信される．ブラウザ/CDNのキャッシュも考慮する．

Q6．デプロイを自動化したい

デプロイ手順をスクリプト化しCI/CDに組み込む(CI/CD記事参照)．「コード→依存→アセット→マイグレーション→再起動」を自動化すれば手作業のミスが消える．デプロイ前スナップショットも仕込むと安全だ．

まとめ ― 要素が多いからこそ「手順」と「戻せる備え」

Rails/Laravelの本番デプロイは，アプリサーバー＋Nginx，環境変数，マイグレーション，アセット，ジョブワーカーを正しい順序で扱うことが要点だ．要素が多いぶん，手順の自動化と「戻せる」備えが効く．

今日やるべきことは，本番で開発サーバーを使っていないか，APP_DEBUGがfalseか，マイグレーションがデプロイ手順に入っているかを確認すること．

フルスタックの安定運用は，余裕のあるVPSとスナップショットの上に築かれる．手順を固め，戻せる備えを持って，安心して公開しよう．