01 / 新規アプリの配置先を用意する
PHP 8.3とComposerの準備を完了し、サーバーの一般管理者で操作します。rootでComposerを実行しません。ここでは新規専用の/var/www/laravel-guideへLaravel 13を作り、SQLiteで初期確認します。既存アプリの上書き、DB移行、公開ドメインの設定は別の作業です。
配置先が存在する場合は中断し、用途と所有者を確認します。DEPLOY_USERは今ログインしている配置担当者で、撮影用のユーザー名に合わせる必要はありません。
id -un
id -u
DEPLOY_USER="$(id -un)"
sudo test ! -e /var/www/laravel-guide &&
sudo install -d -o "$DEPLOY_USER" -g www-data -m 2750 /var/www/laravel-guide
umask 0027
php8.3 "$HOME/.local/bin/composer" create-project 'laravel/laravel:^13.0' /var/www/laravel-guide --no-dev --prefer-dist --no-interaction依存のダウンロードと生成処理がエラーなく完了したことを確認します。Laravelのバージョン制約は13系ですが、取得される修正版は時期で変わります。composer.lockと実バージョンを保存してください。.env・APP_KEY・資格情報は公開せず、Gitにも含めません。
cd /var/www/laravel-guide
php8.3 artisan --version
php8.3 "$HOME/.local/bin/composer" check-platform-reqs --no-devcreate-projectは新規.env、アプリ鍵、初期SQLiteやマイグレーション等を自動実行する場合があります。メッセージを読み、何が作られたか確認します。初期のローカル用設定をそのまま公開しないでください。
02 / 公開用設定と新規SQLiteを用意する
SQLiteは初期確認のための単一サーバー構成です。Web公開先の外に専用データ領域を作り、アプリのコードやdatabase/migrationsをWebプロセスへ書き込み可能にしません。既存DBのデータが必要な場合は、空DBへ切り替えるこの手順を実行せず、先に移行と復元を計画します。
DEPLOY_USER="$(id -un)"
sudo test ! -e /var/lib/laravel-guide &&
sudo install -d -o "$DEPLOY_USER" -g www-data -m 2770 /var/lib/laravel-guide
test ! -e /var/lib/laravel-guide/database.sqlite &&
touch /var/lib/laravel-guide/database.sqlite
sudo chown "$DEPLOY_USER":www-data /var/lib/laravel-guide/database.sqlite
chmod 660 /var/lib/laravel-guide/database.sqliteプロジェクトの.envをnano .env等、自分の権限で編集します。以下は設定ファイルの例で、シェルへ貼り付けて実行するコマンドではありません。laravel-guide.testは、この手順の名前付きVirtualHostへ合わせた検証用の名前です。管理端末のhosts設定やcurlのHost指定で使い、公開DNSへ登録する本番名とは区別します。本番では所有する実ドメインのHTTPSを先に用意し、そのURLへ置き換えてください。同名の項目は重複させず既存行を変更します。
APP_ENV=production
APP_DEBUG=false
APP_URL=http://laravel-guide.test
DB_CONNECTION=sqlite
DB_DATABASE=/var/lib/laravel-guide/database.sqlite新規作成でAPP_KEYがすでに設定されているなら、その値を保ちます。空の新規アプリの場合だけphp8.3 artisan key:generateを実行します。鍵を表示する--showは使いません。既存アプリの鍵を再生成すると暗号化済みデータやセッションへ影響するため、復旧・移行時に作り直さないでください。
MariaDBを使う場合はDBの権限設定を参考にLaravel専用DBとユーザーを作り、接続設定を変更します。WordPress用DBやrootアカウントを共用しません。このページのSQLite確認を、そのままMariaDBの接続検証と扱わないでください。
03 / コードと書き込み先の権限を分ける
コードは配置担当者が管理し、Webプロセスは読み取りだけにします。書き込める場所はstorage、bootstrap/cacheと専用DB領域に限定します。以下は、この新規プロジェクトを作成した配置担当者が操作する例です。
cd /var/www/laravel-guide
DEPLOY_USER="$(id -un)"
sudo chown -R "$DEPLOY_USER":www-data /var/www/laravel-guide
find /var/www/laravel-guide -type d -exec chmod 2750 {} +
find /var/www/laravel-guide -type f -exec chmod 640 {} +
find storage bootstrap/cache -type d -exec chmod 2770 {} +
find storage bootstrap/cache -type f -exec chmod 660 {} +
chmod 640 .env
stat -c '%a %U %G %n' .env storage bootstrap/cache /var/lib/laravel-guide /var/lib/laravel-guide/database.sqliteFPMとCLIは異なるユーザーでファイルを作ります。最初のsetgidと660だけでは、後でFPMが作るログ等へ配置担当者が書き込めない場合があるため、この3つの書き込み先だけにアクセスACLと継承用のdefault ACLを設定します。準備ページのaclパッケージが必要です。コード全体や.envへ書き込みACLを広げません。
sudo setfacl -R -m u:"$DEPLOY_USER":rwX,u:www-data:rwX storage bootstrap/cache /var/lib/laravel-guide
sudo find storage bootstrap/cache /var/lib/laravel-guide -type d -exec setfacl -m d:u:"$DEPLOY_USER":rwx,d:u:www-data:rwx,d:m:rwx {} +
getfacl storage bootstrap/cache /var/lib/laravel-guide新しいログやキャッシュについても、配置担当者とFPMの両方が必要な読み書きをできるか確認します。ACLが使えないファイルシステムの場合はここで中断し、同じアクセス範囲を保てる運用ユーザー・グループ・作成モードを設計してください。
Webサーバー側の実行ユーザーが必要なグループに属し、親ディレクトリーを通過できることも確認します。Caddyの補助グループやFPMへの接続は次のページで製品別に扱います。権限エラーをchmod 777やプロジェクト全体のWebユーザー所有への変更で回避しません。
04 / DB初期化と本番用キャッシュを確認する
設定変更後は古い設定キャッシュを消し、新規DBへマイグレーションします。--forceは本番環境の確認プロンプトを省く指定で、DBを消す指定ではありません。ただし実際のスキーマ変更なので、既存データがある場合は先にバックアップと内容確認が必要です。
cd /var/www/laravel-guide
php8.3 artisan config:clear
php8.3 artisan migrate --force
php8.3 artisan migrate:status
php8.3 artisan config:cache
php8.3 artisan route:cache
php8.3 artisan view:cache
php8.3 artisan about --only=environmentマイグレーションが実行済みで、環境がproduction、デバッグが無効であることを確認します。設定を変更したときはキャッシュを作り直します。設定キャッシュ後に.envだけ編集しても反映されない場合があります。失敗はstorage/logs等で調べますが、ログの秘密情報をそのまま共有しません。
本ガイドはスターターキットを使わない基本アプリです。Node.js/Vite、認証機能、メール、キューワーカー、スケジューラーの設定・動作は対象外です。フロント資産を使うアプリは、そのアプリのビルド手順と生成物を別途確認してください。
参考：実行結果と表示画面
Ubuntu Server 22.04.5の実VMで一般ユーザーがLaravel 13.39.0（スケルトン13.11.0）を作成しました。プラットフォーム要件確認は成功し、Composer監査では確認時点の脆弱性アドバイザリは0件でした。APP_ENV=production・APP_DEBUG=falseをキャッシュへ反映し、公開領域外のSQLiteへのマイグレーションと設定参照を確認しています。CLIとFPMの両ユーザーが新規ログ/キャッシュへ書き込め、FPMがコードと.envへ書き込めない権限も確認しました。これは基本導入の試験で、個別アプリの安全性や将来の監査結果を保証しません。
05 / Web設定と、その後の配置を分ける
ここまでの完了条件は、対応PHPでアプリが生成され、DBと設定キャッシュが初期化できることです。Webサーバーの公開先はプロジェクト全体ではなく、/var/www/laravel-guide/publicだけです。次のWebサーバーへの接続で、Nginx・Apache・Caddyのうち使う1つを設定します。
php artisan serveや8000番の開発サーバーは、本番公開の方法として使いません。.env、composer.json、vendorや非公開のDBファイルを配信しないこと、通常の画面とヘルスチェックが返ることを確認してから公開します。
開発したコードを後日配置するときは、検証済みのコードとcomposer.lockを使い、配置担当者が依存を再現します。新規作成用のcreate-projectを運用中アプリへ繰り返し実行しません。
php8.3 "$HOME/.local/bin/composer" install --no-dev --optimize-autoloader --no-interaction
php8.3 "$HOME/.local/bin/composer" check-platform-reqs --no-dev
php8.3 "$HOME/.local/bin/composer" audit --locked --no-dev監査に接続できなかった状態と「問題が見つからなかった」結果は別です。失敗や依存の不整合を無視せず、修正後に再確認します。復旧に備え、コード、.envと既存のアプリ鍵、DBを一組としてWeb公開領域・Gitの外へ安全に保管します。DB変更後にコードだけ戻して整合性を失わないよう、復元計画を先に用意してください。