Laravelをレンタルサーバーで公開する｜既存サイトのDBを変更しない配置と確認

GitHubのサンプルをブラウザーでも試せるよう、学習用Laravelアプリをレンタルサーバーへ配置しました。
既存のWordPressとそのDBを変更しないことが条件です。

学習用に専用SQLiteを新規作成し、本番設定とHTTPSでの動作を確認しました。
テーブルを作成したのはこのSQLiteだけで、WordPressのMariaDBには接続・変更していません。

公開中の学習用アプリを開く

説明は2026年11月時点のものです。
事業者名と実際のフォルダー構成は伏せ、図は役割と作業の流れ、設定例は仮値を示します。
公開URLは上のリンクに掲載しています。

配置前に、変更する範囲を固定する

配置するコード・置き場所と、既存サイトへの変更範囲を決めました。
対象は共通一覧と学習用だけで、業務用アプリは未追加です。

配置前の退避と資材確認は、次の順に進めました。

1. 公開先の既存ファイルと関連設定を非公開領域へ退避する。
2. 変更しない設定ファイルのハッシュを記録する。
3. 固定コミットから配置資材を作り、転送する。
4. 転送後のアーカイブとファイル一覧のハッシュを照合し、用意した資材との一致を確かめる。

専用の本番設定とSQLiteを用意する

設定・鍵・DB・ログは、アプリ専用の非公開領域で管理します。
本番設定でデバッグ表示を無効にし、接続先を専用SQLiteへ向けました。

次は設定例です。
仮のパスは、実際の非公開領域へ置き換えます。

APP_ENV=production
APP_DEBUG=false
DB_CONNECTION=sqlite
DB_DATABASE=/private/example/demo.sqlite

DB操作前に、接続方式・DBのURL設定・保存先を確認します。
既存サイトの接続情報は流用しません。

初回配置では暗号鍵を生成し、新しいSQLiteへテーブルを作成しました。
次はアプリ本体のフォルダーで実行する例です。
PHPの実行ファイル名は、Laravelの要件を満たすサーバー側のものに合わせます。

php8.3 artisan key:generate --no-interaction
php8.3 artisan migrate --force --no-interaction

実行時は、次の点を区別します。

専用SQLiteのテーブル作成と整合性検査は成功しました。

保守状態のままWeb側の設定を確認する

配置後は保守状態で設定を確認しました。
本体の外に置く専用フラグがある間、対象アプリは503を返し、静的な共通一覧は表示を続けます。

CLIでの起動に加え、Web側でも次を確認しました。

• 使用されるPHPと本番環境の設定。
• デバッグ表示とPHPのエラー表示が無効であること。
• DBドライバーがSQLiteで、専用ファイルを参照していること。
• 公開パスと、セッション・ビュー・キャッシュ等の書込み可否。

一時診断はランダムな名前とヘッダー認証で保護し、必要項目だけを返しました。
鍵・接続資格情報・実パス・phpinfo()の内容は公開せず、確認後に診断ファイルを削除しました。

設定・ルート・ビューのキャッシュは、サーバー上の最終配置場所で作成しました。
ローカルの設定キャッシュは流用せず、環境に合わない設定の持込みを防ぎます。

HTTPSで操作と既存サイトへの影響を確かめる

設定確認後に保守を解除し、公開URLで画面表示・入力・送信・コピー・エラー応答をテストしました。

設定ファイルへの要求には、ローカルの404に対し、実サーバーのApacheが403を返す箇所もありました。
拒否の成否はステータスと応答本文の両方で判断しました。

WordPress設定ファイルと上位の振り分け設定は、配置後もハッシュが一致しました。
管理者ログイン後の操作・スマホ実機・他ブラウザーは未確認です。

次のアプリを追加するときも、対象を分ける

追加するアプリも、本体・公開入口・設定・DB・鍵を個別に用意し、共通一覧へリンクを追加します。
更新・切戻しは対象アプリだけで行い、公開入口全体や他のアプリを巻き込みません。

初回配置・Web設定確認・公開後の検証は、今後の公開・更新・切戻し用の手順にまとめました。
本番での切戻し操作は未実施です。
更新前に、前の版へ戻せる範囲と、DB変更時のデータの扱いを確認します。