【Laravel】Laravelアプリを本番環境にデプロイする流れ

laravelアイキャッチ Laravel
2025.06.12

こんにちは、かつコーチです。

前回は、GitHub Actionsでテストを自動化するCIの仕組みを解説しました。

テストが安心して通せるようになったら、次はいよいよ「本番環境にアプリを届ける」というステップに進みます。

ここから数回にわたって、デプロイ・インフラ連携編としてLaravelアプリを実際に世の中に公開するために必要な知識をまとめていきます。

今回は、その入り口として「デプロイとは何をすることなのか」「どんな流れで進めるのか」を全体像から整理します。

デプロイとは？何をすることなのか

「デプロイ」の意味を整理する

デプロイ（deploy）とは、開発したアプリケーションを、実際にユーザーがアクセスできるサーバーに配置し、動かせる状態にすることです。

ローカル環境で php artisan serve を使って動作確認するのと、本番のサーバー上でアプリを公開するのとでは、必要な作業がまったく違います。

ローカルと本番で異なる前提条件

ローカル開発では意識しなくても済んでいたことが、本番では急に重要になります。

  • 複数人が同時にアクセスしても耐えられるか（パフォーマンス）
  • サーバーが再起動してもデータが消えないか（永続化）
  • 不正アクセスから守れているか（セキュリティ）
  • エラーが起きたときにすぐ気づけるか（監視・ログ）

これらを踏まえたうえで、サーバーにコードを配置し、必要な設定を行うのがデプロイ作業です。

デプロイ先の選択肢と選び方

主な選択肢とその特徴

Laravelのデプロイ先にはいくつかの選択肢があり、それぞれ管理の手間とコストのバランスが異なります。

選択肢特徴こんな人におすすめ
VPS（さくらVPS、ConoHa等）サーバーを自分で構築・管理サーバー構成を細かく理解したい人
Laravel Forgeサーバー構築・デプロイを自動化するSaaS構築の手間を減らしたいがVPSは使いたい人
Laravel VaporAWS上でサーバーレス運用するSaaSアクセス数の変動が大きいサービス
PaaS（Heroku、Railway等）サーバー管理不要、gitプッシュで公開とにかく早く公開したい小規模アプリ
共用レンタルサーバー低コストだが自由度は低い小規模な個人サイト

どれを選べばいいかの判断軸

初めて本番デプロイを経験するなら、私はVPS + 手動構築を一度は経験しておくことを勧めています。

理由はシンプルで、Nginx・PHP-FPM・MySQLがどう連携して1つのリクエストを処理しているのかを、自分の手で構築すると体で理解できるからです。

Laravel ForgeやVaporのような自動化サービスは非常に便利ですが、「中で何が起きているか分からないまま動いている」状態だと、エラーが起きたときに対処できません。

ある程度VPSでの構築を経験したうえで、業務効率を優先する場面ではForgeやVaporに切り替える、という順番がおすすめです。

デプロイの基本的な流れ

ステップ1：サーバー環境の準備

まず、本番サーバーにPHP・Composer・Webサーバー（NginxまたはApache）・データベースをインストールします。

# Ubuntu環境でのインストール例（一部抜粋）
sudo apt update
sudo apt install php8.3-fpm php8.3-mbstring php8.3-xml php8.3-mysql
sudo apt install nginx mysql-server composer

PHPのバージョンは、開発環境と本番環境でズレがないように必ず揃えておきます。

ステップ2：コードの配置

Gitを使ってリポジトリを本番サーバーにクローンします。

cd /var/www
git clone https://github.com/your-account/your-laravel-app.git
cd your-laravel-app

ステップ3：依存関係のインストール

本番環境では、開発用のパッケージを含めずにインストールします。

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

--no-dev をつけることで、テストやデバッグ用のパッケージを除外し、余計な依存関係を持ち込まないようにします。

ステップ4：環境変数とアプリケーションキーの設定

.env ファイルを本番用の内容に設定します。

cp .env.example .env
php artisan key:generate

.env の詳しい管理方法は、次回の記事で詳しく扱います。

ステップ5：マイグレーションの実行

本番のデータベースにテーブルを作成します。

php artisan migrate --force

本番環境では、対話的な確認プロンプトが出ないように --force オプションをつける必要があります。

ステップ6：パーミッションの設定

storage ディレクトリと bootstrap/cache ディレクトリに、Webサーバーからの書き込み権限を与えます。

sudo chown -R www-data:www-data storage bootstrap/cache
sudo chmod -R 775 storage bootstrap/cache

つまずきやすいポイント：パーミッション設定忘れによる500エラー

私が実際に体験した「原因不明の500エラー」

初めて本番デプロイをしたとき、ブラウザでアプリにアクセスすると真っ白な画面に「500 Internal Server Error」とだけ表示され、原因がまったく分かりませんでした。

❌ Before：パーミッション設定を省略してしまう

git clone https://github.com/your-account/your-laravel-app.git
cd your-laravel-app
composer install --no-dev
php artisan migrate --force
# このままpermissionを設定せずに公開してしまう

原因を探るために storage/logs/laravel.log を見に行こうとしたところ、そもそもそのログファイル自体が作成できていませんでした。

storage ディレクトリの所有者がデプロイ時のユーザーのままになっていて、Webサーバーを動かしている www-data ユーザーには書き込み権限がなかったのです。

Laravelはログ・キャッシュ・セッションなどを storage 配下に書き込みますが、書き込み権限がないと、そのエラー自体もログに残せず「何も表示されない500エラー」になってしまいます。

✅ After：パーミッションを正しく設定してから公開する

git clone https://github.com/your-account/your-laravel-app.git
cd your-laravel-app
composer install --no-dev
php artisan migrate --force

# Webサーバーのユーザーに書き込み権限を与える
sudo chown -R www-data:www-data storage bootstrap/cache
sudo chmod -R 775 storage bootstrap/cache

この経験以降、私はデプロイ手順の中に「パーミッション設定」を必ず1項目として書き出し、チェックリスト化するようにしています。

デプロイ後に必ず確認すること

本番用の設定になっているかのチェック

デプロイが終わったら、以下の項目を必ず確認しましょう。

  • .env の APP_ENV が production になっているか
  • .env の APP_DEBUG が false になっているか（デバッグ情報の漏洩防止）
  • HTTPS化されているか（SSL証明書の設定）
  • エラーログが正しく storage/logs/laravel.log に出力されているか

特に APP_DEBUG=true のまま本番公開してしまうと、エラー発生時にデータベースの接続情報やソースコードの中身までブラウザに表示されてしまうため、セキュリティ上の重大なリスクになります。

応用：デプロイを自動化する考え方

手動デプロイの限界

ここまで紹介した手順は、すべて手動でサーバーにログインして実行する前提でした。

チームでの開発が進んでくると、この手動作業自体がミスの温床になります。

「パーミッション設定を忘れた」「マイグレーションを実行し忘れた」といった、前述のようなヒューマンエラーは、手順が増えるほど発生しやすくなります。

CI/CDへの接続

前回解説したGitHub Actionsを使えば、テストが通った後に自動でデプロイまで実行する「CI/CD（継続的デプロイ）」の仕組みを作ることができます。

deploy:
  needs: test
  if: github.ref == 'refs/heads/main'
  runs-on: ubuntu-latest
  steps:
    - name: SSHでサーバーに接続してデプロイ
      uses: appleboy/ssh-action@v1
      with:
        host: ${{ secrets.SERVER_HOST }}
        username: ${{ secrets.SERVER_USER }}
        key: ${{ secrets.SERVER_SSH_KEY }}
        script: |
          cd /var/www/your-laravel-app
          git pull origin main
          composer install --no-dev --optimize-autoloader
          php artisan migrate --force
          php artisan config:cache

ここで登場する secrets.SERVER_HOST のような環境変数の安全な扱い方については、次回の記事で詳しく解説します。

まとめ

この記事のポイント

  • デプロイとは、開発したアプリを本番サーバーに配置し、ユーザーがアクセスできる状態にすること
  • デプロイ先にはVPS・Forge・Vapor・PaaSなど複数の選択肢があり、まずはVPSでの手動構築を経験しておくと理解が深まる
  • デプロイの基本手順は「環境準備→コード配置→依存関係インストール→環境変数設定→マイグレーション→パーミッション設定」の流れ
  • storage と bootstrap/cache のパーミッション設定漏れは、原因不明の500エラーの典型的な原因になる
  • APP_DEBUG=false の確認など、本番用設定への切り替えは公開前に必ずチェックする

次に読むべき記事

デプロイの流れが分かったところで、次は手順の中で何度も登場した .env ファイルの安全な管理方法について詳しく見ていきます。

→ 次の記事：環境ごとの.env管理とシークレット情報の扱い方

タイトルとURLをコピーしました