本番公開までの手順を、順番どおりに1つずつ

本番用の .env を整え、アプリのキーを用意する土台づくり

• .env を本番用に設定する

  なぜ必要か

  本番では動作モードを production にし、デバッグ表示を必ず切ります。APP_DEBUG=true のままだと、エラー画面に設定値やスタックトレースが露出し、重大な情報漏えいにつながります。

  コマンド / 設定

  APP_ENV=production
  APP_DEBUG=false
  APP_URL=https://example.com

  💡.env は Git に含めず、本番サーバー上で個別に用意します。

• APP_KEY を生成する

  なぜ必要か

  APP_KEY はセッションや暗号化・署名付きURLなどの土台になる暗号鍵です。未設定だと暗号化が働かず、アプリが正しく動きません。本番では本番専用の鍵を1度だけ生成します。

  コマンド / 設定

  php artisan key:generate

• DB・メール・キャッシュ等の接続情報を設定する

  なぜ必要か

  本番のデータベース・メール送信・キャッシュ/セッション/キューの保存先を .env で指定します。開発用のダミー設定のままだと、接続エラーやメール未達の原因になります。

  コマンド / 設定

  DB_CONNECTION=mysql  DB_HOST=...  DB_DATABASE=...
  MAIL_MAILER=smtp  MAIL_HOST=...  MAIL_USERNAME=...
  SESSION_DRIVER=database  QUEUE_CONNECTION=database

本番向けに依存パッケージとフロント資産を用意する

• 本番用に依存パッケージをインストールする

  なぜ必要か

  本番では開発専用パッケージ(テスト等)は不要です。--no-dev で除外し、--optimize-autoloader でオートローダを最適化すると、読み込みが速くなります。

  コマンド / 設定

  composer install --no-dev --optimize-autoloader

• フロント資産をビルドする

  なぜ必要か

  CSS/JS はブラウザ向けに圧縮・最適化した「本番ビルド」が必要です。npm ci はロックファイル通りに正確に入れ、npm run build で公開用の資産を生成します。

  コマンド / 設定

  npm ci && npm run build

  💡ビルド成果物(public/build 等)をサーバーへ反映するのを忘れずに。

テーブル構成を本番DBへ反映する

• マイグレーションを実行する

  なぜ必要か

  テーブル構成(スキーマ)を本番DBへ反映します。本番では確認プロンプトが出るため、--force を付けて自動で適用します。実行前のバックアップを推奨します。

  コマンド / 設定

  php artisan migrate --force

  💡--force は破壊的操作を含むことがあるため、必ずバックアップ後に。

設定・ルート・ビューを事前キャッシュして高速化する

• 設定をキャッシュする

  なぜ必要か

  毎回すべての config ファイルを読むのは無駄です。1つのファイルにまとめてキャッシュすると、起動が速くなります。設定を変更したら必ず作り直します。

  コマンド / 設定

  php artisan config:cache
  # 変更時: php artisan config:clear

  💡config:cache 後は .env が直接読まれません。env() は config 経由で。

• ルートをキャッシュする

  なぜ必要か

  ルート定義を1ファイルにまとめて読み込みを高速化します。ルートを追加・変更したら作り直しが必要です。

  コマンド / 設定

  php artisan route:cache
  # 変更時: php artisan route:clear

  💡クロージャで書いたルートがあると route:cache は失敗します。

• ビューをキャッシュする

  なぜ必要か

  Blade テンプレートを事前にコンパイルしておくと、初回表示が速くなります。テンプレートを変更したら作り直します。

  コマンド / 設定

  php artisan view:cache
  # 変更時: php artisan view:clear

  💡まとめて行う php artisan optimize / optimize:clear も便利です。

• storage:link でシンボリックリンクを作る

  なぜ必要か

  アップロードした画像などを公開するには、storage/app/public を public/storage から見えるようにリンクします。これが無いと保存したファイルにWebからアクセスできません。

  コマンド / 設定

  php artisan storage:link

権限・常駐処理・HTTPS・監視など、動かし続ける仕組みを整える

• ディレクトリ権限を設定する

  なぜ必要か

  Laravel は storage/ と bootstrap/cache/ にログ・キャッシュ・セッションを書き込みます。Webサーバーが書き込めないと「Permission denied」で真っ白になります。

  コマンド / 設定

  chmod -R ug+rwx storage bootstrap/cache
  chown -R www-data:www-data storage bootstrap/cache

• キュー worker を常駐させる

  なぜ必要か

  メール送信や重い処理をキューに逃がしている場合、それを処理する worker を動かし続ける必要があります。Supervisor 等で監視し、落ちても自動で再起動させます。

  コマンド / 設定

  php artisan queue:work --daemon
  # Supervisor で常時監視・自動再起動を設定

  💡デプロイでコードを更新したら queue:restart で worker を入れ替えます。

• スケジューラ(cron)を登録する

  なぜ必要か

  Laravel のタスクスケジュール(定期処理)は、cron が1分ごとに schedule:run を呼ぶことで動きます。cron の登録を忘れると定期処理がまったく走りません。

  コマンド / 設定

  * * * * * cd /path && php artisan schedule:run >> /dev/null 2>&1

• HTTPS/SSL を有効にする

  なぜ必要か

  本番は必ず HTTPS にします。通信を暗号化して盗聴・改ざんを防ぎ、Cookieやログイン情報を守るためです。証明書を設定し、http は https へリダイレクトします。

  💡APP_URL を https に。プロキシ配下なら TrustProxies の設定も確認。

• ログ・監視を整える

  なぜ必要か

  本番では画面にエラーを出さない代わりに、ログへ記録します。ログの保存先とローテーションを設定し、異常を検知できる監視/通知を用意しておくと、障害に素早く気づけます。

  コマンド / 設定

  LOG_CHANNEL=stack  LOG_LEVEL=error

  💡storage/logs/laravel.log が肥大化しないようローテーションを。

• メンテナンスモードを使い分ける

  なぜ必要か

  デプロイ中に中途半端な状態を見せないよう、作業前に down で停止し、完了後に up で再開します。--secret を使えば、自分だけは確認しながら作業できます。

  コマンド / 設定

  php artisan down --secret="..."
  php artisan up

実際に動くか、エラーが出ていないかを最後に点検する

• 実際の動作を確認する

  なぜ必要か

  デプロイが成功しても、本番特有の設定ミスで動かないことがあります。トップページ・ログイン・フォーム送信・画像表示など、主要な導線を実際に触って確認します。

  💡HTTPS表示・画像(storage:link)・メール送信も忘れず点検。

• エラーログを確認する

  なぜ必要か

  画面が正常に見えても、裏でエラーが出ていることがあります。デプロイ直後にログを確認し、想定外の警告・例外が出ていないかを点検します。

  コマンド / 設定

  tail -f storage/logs/laravel.log