Laravel Forgeとは｜自動化される範囲・料金・Cloudとの選択基準

Laravel Forgeは、自分名義のクラウドアカウント上にサーバを建て、そこにPHPアプリが動く状態を組み上げて維持し続けるためのコントロールプレーンです。サーバそのものはDigitalOceanやAWSなど手元のプロバイダに残り、Forgeが引き受けるのはNginxやPHPの導入、SSLと通信制御の設定、キューやスケジュール実行の常駐化、そしてGitからのデプロイという工程です。この記事では2026年8月30日時点の公式ドキュメントと料金ページを実測し、Forgeが自動化する範囲、デプロイスクリプトを自分で書く部分との境目、定額料金とサーバ代の積み上がり方を整理したうえで、受託開発で採用してよい条件を条件付きで示します。サーバを持たずにマネージド基盤へ寄せる選択肢はLaravel Cloudとは｜構成・料金・ForgeとVaporの違いと受託での採用条件にまとめてあります。

まとめ：自動化される範囲と料金の構造、Cloudとの分岐点

• Forgeはホスティングではなくサーバ管理サービスです。サーバの所有者も請求先も手元のプロバイダのまま変わらず、SSHとroot権限も残ります。裏返すとOSの更新やプロバイダ側の権限設計は自分の責任として残り続けます。
• 払い出せるサーバはApp・Web・Database・Cache・Worker・Meilisearch・Load Balancerの7種類で、タイプごとに導入されるミドルウェアが変わります。1台完結ならApp Serverが既定の選択になります。
• Laravel VPSはDigitalOceanとの提携で提供されるUbuntuサーバで、秒単位の払い出しと請求のForge一本化が特徴です。外部プロバイダ経由の払い出しは10分を超える場合があります。
• デプロイはForgeが実行と記録を受け持ち、実行内容のスクリプトは書く側が用意します。ゼロダウンタイムはリリースディレクトリの切り替えで実現しますが、新規サイト作成時にしか設定できず後付けはできません。
• 費用はForgeの定額（Hobby 月12ドル／Growth 月19ドル／Business 月39ドル）とプロバイダのサーバ代の二階建てです。Hobbyは外部サーバが1台までという上限があり、受託の複数案件を1契約でさばく用途には届きません。
• Cloudとの分岐は機能表ではなく「サーバの所有と請求を顧客側に残すかどうか」の一点で決まると判断しています。顧客のクラウド勘定に載せる要件、OS層へ手を入れる要件、非Laravelのアプリを同居させる要件のいずれかがあるならForge側が噛み合います。

Forgeが引き受けるのはサーバの構築と設定と維持までの作業範囲

名前だけを見ると独自のホスティング環境のように読めますが、Forgeが提供するのは管理画面とその裏で走る自動化であって、計算資源そのものではありません。この前提を外すと料金の見積もりも責任分界点の説明も崩れます。

サーバタイプは7種類あり、入るミドルウェアが役割ごとに変わる

サーバを新規作成するとき、まず決めるのがタイプです。公式が用意しているのは次の7種類で、それぞれ導入されるソフトウェアが異なります。役割を分けた構成にすると、私設ネットワーク越しに互いを参照させる形になります。

App Serverには1台で動かすための一式がまとめて導入される

迷ったときの既定はApp Serverです。ここにはPHP、Nginx、選択したデータベース（MySQL・PostgreSQL・MariaDBのいずれか）、Redis、Memcached、Node.js、Supervisorが導入されます。Laravelアプリが前提にするミドルウェアがほぼ揃った状態で立ち上がるため、払い出し直後にリポジトリをつなげばデプロイまで進めます。

Laravel VPSは秒単位の払い出しと請求の一本化を引き受ける

Laravel VPSは、DigitalOceanとのインフラ提携をもとにForge側から直接払い出せるUbuntuサーバです。外部プロバイダを連携させる従来の経路では払い出しに10分を超えることがありますが、こちらは秒単位で終わります。請求もプロバイダとForgeの二重ではなくForgeへ寄り、稼働した時間分だけが積み上がる形です。課金は1時間単位で丸められるため、5分だけ立てたサーバも1時間分として計上されます。

制約もいくつかあります。メール送信ポート（25・465・587）は不正利用を防ぐため既定で閉じており、サーバから直接メールを出す構成は取れません。API型の送信サービスへ寄せるか、サポートへ開放を依頼する流れになります。既存のDigitalOceanドロップレットからの移行はUbuntu 24.04のサーバだけが対象で、それ以前の版は移行できません。さらにLaravel VPSのサーバはアーカイブができず、組織間の移管も現時点では対象外、リサイズも拡大方向にしか動きません。案件の途中でスペックを絞る運用なら、この非対称性は先に共有しておくべき条件になります。

SSHとroot権限は手元に残り、OSの更新責任もそのまま残る

Forgeは構築と設定を代行しますが、サーバの中身を隠しません。SSHで入ってrootとして操作でき、追加のシステムパッケージも自由に入れられます。これはCloudのようなマネージド基盤との決定的な違いで、独自のバイナリを常駐させる、特殊なPHP拡張を導入する、カーネルパラメータを触るといった要件をそのまま通せます。

同じ性質が運用側の負担にもなります。OSのセキュリティ更新、プロバイダ側のIAM設計、鍵の棚卸しはForgeの守備範囲の外に残るため、納品後の保守契約で誰が見るのかを決めておく必要があります。サーバのタイムゾーンは既定でUTCなので、ログの時刻やスケジュール実行の設計を日本時間で組むなら初期設定で切り替えてください。AWSのサーバは再起動でIPアドレスが変わる仕様があり、変わった場合はForge側の接続先も手で更新しないと管理が切れます。ローカル側の環境をどう組むかは別の話になるので、Laravel Sailとは｜sail up・sail downなど基本コマンドの使い方と導入手順とLaravel Herdとは｜PHPバージョン切替と.test公開の仕組み・Sailとの使い分けを参照してください。

デプロイの自動化はどこまでが既定で、どこから自分で書くのかを分ける

Forgeの説明でいちばん誤解が生まれるのがデプロイ周りです。押すだけで公開されると読めますが、実際に走るコマンド列は書く側が用意します。何が自動で、何が手書きなのかを工程順に見ていきます。

スクリプトの中身は書く側が用意し、実行と記録だけが自動になる

デプロイが起動すると、Forgeはサイトごとに保存されたデプロイスクリプトをそのまま実行します。最低限必要なのはコードの更新、依存の導入、アプリを動かせる状態にするための処理です。実行結果は履歴の一覧に、何をいつデプロイして何秒かかったか、標準出力に何が出たかまで残ります。

実行時間には10分の上限があり、超えると自動で失敗扱いになります。ビルドの重いフロントエンドを同じスクリプトで抱えていると、この壁に当たることがあるでしょう。GitHubのソース連携を使っている新規サイトでは「Push to deploy」が既定で有効なので、対象ブランチへの押し込みがそのまま本番反映になる点は初回に必ず確認してください。既存サイトで有効にする場合は、サイト設定のデプロイ画面から個別に切り替えます。

ゼロダウンタイムはリリース単位の切り替えによって実現している

ゼロダウンタイムデプロイを有効にすると、新しいコードはreleases配下の新規ディレクトリへcloneされ、全工程が成功した時点でシンボリックリンクを張り替えて切り替わります。途中でどれか1手順が失敗すれば、公開中のリリースはそのまま動き続けます。同一ディレクトリを上書きしていく標準デプロイに比べると、失敗時に中途半端な状態が公開される事故が構造的に起きません。

3つのマクロが新旧リリースの生成と切り替えを実際に受け持っている

ゼロダウンタイムを有効にしたサイトのデプロイスクリプトには、3つのマクロが自動で挿入されます。リリース生成のマクロが新しいディレクトリを作ってコードを取得し、有効化のマクロがシンボリックリンクを張り替え、キュー再起動のマクロがワーカーとHorizonのプロセスを立て直します。これらを消すと切り替えが走らないため、スクリプトを書き換えるときは残す前提で編集してください。

$CREATE_RELEASE()
cd $FORGE_RELEASE_DIRECTORY
$FORGE_COMPOSER install --no-dev --no-interaction --prefer-dist
$FORGE_PHP artisan migrate --force
npm ci
npm run build
$ACTIVATE_RELEASE()
$RESTART_QUEUES()
sudo supervisorctl restart daemon-12345:*

FORGE_接頭辞の環境変数でデプロイ内容に応じた分岐を書ける

実行時には、そのデプロイが何であったかを示す変数群が注入されます。19種類ほどあり、主なものは次のとおりです。自分で定義する変数にこの接頭辞を使うと衝突する恐れがあるため、命名は避けたほうが無難でしょう。

これらは通常のシェル変数として扱えるため、条件によってデプロイを止める分岐が書けます。作業途中のコミットを本番へ流さない安全弁として、次の数行を頭に置いておくと事故が減りました。

if [[ $FORGE_DEPLOY_MESSAGE =~ "wip" ]]; then
    echo "作業中のコミットのため中止します"
    exit 1
fi

CIから叩く経路はデプロイフックとForge CLIの2つに分かれる

GitHub Actionsなどのパイプラインを通してから本番へ流したい場合、利用できる経路は2つです。ひとつはサイトごとに発行されるデプロイフックのURIで、GETまたはPOSTを投げるだけで起動する仕組みです。forge_deploy_branchのような予約クエリを付けると対象ブランチの一致判定が働き、任意のクエリを渡すとFORGE_VAR_接頭辞の変数としてスクリプトへ届きます。トークンは画面から再発行でき、再発行した瞬間に旧トークンは無効になります。

もうひとつがForge CLIです。こちらはデプロイの出力を取得でき、サービスの再起動といった追加操作も実行できます。CI側にFORGE_API_TOKENとサーバへのSSHアクセスを渡す前提です。テストが通った場合だけ本番へ流す構成を作るなら、出力を握れるCLI経由のほうが失敗の切り分けが速くなります。

composer global require laravel/forge-cli
forge server:switch your-server-name
forge deploy your-site-name.com

費用はForgeの定額とサーバ代の二階建てで積み上がっていく

見積もりを外しやすいのが料金です。Forgeの表示価格はあくまで管理画面の利用料で、サーバの費用はプロバイダ側に別建てで発生します。従量課金ではないので月額は読みやすい反面、稼働していない時間の費用は消えません。

3プランの差はサーバの台数とサポート水準と割引率に集約される

プランは3段構成です。サイト数とデプロイ回数はどのプランでも無制限で、ゼロダウンタイムデプロイ、マネージドデータベース、サーバ監視、チームでの共有、Forge側が提供するホスト名も共通して含まれます。差が出るのは管理できるサーバの台数、サポートの水準、Laravel VPSの割引率です。

Hobbyの外部サーバ1台という上限が受託の現場では効いてくる

月12ドルという表示を見て最小構成から始めたくなりますが、Hobbyで接続できる外部プロバイダのサーバは1台までです。Laravel VPS側は無制限なので、Forgeから払い出したサーバだけで運用するなら台数の制限は当たりません。一方、顧客のAWSアカウントに建てたサーバをつなぐ受託の形では、2案件目の時点でGrowthへ上げる必要が出ます。

Envoyerの扱いは新規契約と既存契約で分かれたままになっている

ゼロダウンタイムデプロイは長らくEnvoyerという別サービスが担っていました。新規のForge契約にはこの機能が含まれるため、追加のサブスクリプションを取る必要はありません。ただし対象は1サーバに限られます。1つのプロジェクトを複数サーバへ同時配信している構成では、Forge側の機能では置き換えられないため、Envoyerの契約を残す判断になります。

受託開発でForgeを採用してよい条件と見送りにする場面の整理

ここからは実案件へ載せる判断の話です。機能表の比較では決まらず、契約の形とサーバの持ち主で答えが変わります。

顧客のクラウド勘定にサーバを残す案件では採用がよく噛み合ってくる

Forgeがもっとも噛み合うのは、サーバが顧客名義のクラウドアカウントに置かれ、その請求も顧客側で完結する案件です。この形ではインフラの所有権が顧客に残るため、契約終了時の引き渡しがアカウントの権限移譲だけで済みます。開発側はForgeの契約を切るだけで手を引け、サーバとデータはそのまま顧客の手元に残ります。

OS層へ手を入れる要件があるならForge以外の選択肢は乏しくなる

特殊なPHP拡張の導入、独自バイナリの常駐、システムパッケージのバージョン固定といった要件が仕様に入っている案件は、マネージド基盤では詰まります。root権限が残るForgeなら、プロビジョニングで整った状態を土台にしたうえで、必要な差分だけを手で入れられます。

非PHPのアプリを同じ管理下に置きたい場合も同様です。ForgeはNode.js、Nuxt、Next.jsのサイトを扱え、素のPHPやWordPress、Statamicも対象に入ります。1つの案件でLaravelのAPIとNext.jsのフロントを別サーバに置く構成でも、管理画面を分けずに運用できます。常駐型のランタイムで性能を稼ぐ設計を併せて検討しているなら、Laravel Octaneとは｜ワーカー常駐の仕組みと状態リーク・採用条件も合わせて読んでください。

サーバを持ちたくない案件はCloud側へ寄せたほうが噛み合う

逆に見送りが妥当なのは、納品後の運用を自社で抱え続け、かつサーバの面倒を見る工数を持たない案件です。ForgeはOSの更新も権限の棚卸しも肩代わりしないため、保守契約に人の時間を確保できないなら、その未処理分がそのまま脆弱性として残ります。台数が増えるほど負担は線形に積み上がります。

トラフィックの山谷が大きい案件も見送り側です。Forgeには自動増減の仕組みがなく、スケールにはインスタンスのリサイズかサーバ追加による手当てが必要になります。しかも常時稼働のサーバ代は、使っていない時間も課金対象です。こうした条件ではマネージド側へ寄せるほうが噛み合い、その具体的な費用構造は前掲のLaravel Cloudの記事で扱っています。どちらの構成を採るにせよ、案件の要件から逆算した設計と構築が要る場面では、AWSインフラ構築（設計・移行・運用）としてご相談を承っています。

分岐はサーバの所有と請求をどちらに置くかという一点だけで決まる

ForgeとCloudの比較表は項目が多く、機能単位で見比べると判断が止まります。実務で効いたのは1つの問いだけでした。サーバの所有と請求を顧客側に残すかどうかです。残す必要があるならForge、残す必要がないならCloudという分け方で、これまでの案件はほぼ説明が付いています。

この問いに対して「どちらでもよい」という答えが返る案件では、運用工数を持てるかで決めています。持てるならForgeで固定費を読みやすくし、持てないならCloudへ寄せて手離れを優先する、という順です。フレームワークそのものを選ぶ段階の判断材料はLaravelの将来性を2026年のデータで判断する｜サポート期限・求人単価・AI対応にまとめてあります。

本番へ載せる前に決めておきたい設定上の前提を3点そろえておく

ここまでの内容を踏まえて、サイトを作る前に決めておくべき項目を挙げます。いずれも後から変えようとすると作り直しになるか、事故として表面化する種類のものです。

ゼロダウンタイムは後付けできないのでサイト作成の時点で決める

公式が明記しているとおり、ゼロダウンタイムデプロイはサイトの新規作成時にしか設定できません。既存サイトへ後から追加する経路は用意されておらず、切り替えるならサイトを作り直すことになります。新規サイトでは既定で有効になっているため、意図的に外す場合だけ作成画面の詳細設定で無効化します。

Octaneを載せるならゼロダウンタイムは有効にしないでおく

Laravel Octaneを使う構成では、ゼロダウンタイムデプロイを有効にしないよう公式が案内しています。Octane自体が内部で無停止の再起動を処理しており、Forge側の切り替えと二重になると挙動が壊れるためです。常駐ランタイムを前提にした構成では、この組み合わせを避けてください。

共有パスにstorageとSQLiteの保存先をあらかじめ寄せておく

リリースごとにディレクトリが変わる方式では、リリースをまたいで残したいファイルを共有パスとして指定します。既定で共有されるのは.envだけなので、ユーザーのアップロード先、生成ファイル、アプリのログ、リリース間で保ちたいキャッシュは自分で登録します。

見落としが致命傷になるのはSQLiteです。データベースファイルを共有パスに入れ忘れると、デプロイのたびに空のファイルへ切り替わり、データが消えたように見えます。ファイル型のデータベースを使う構成では、サイト作成の段階で保存先を共有パスへ登録してください。

よくある質問

Laravel Forgeは無料で試せますか？

無料試用の枠は用意されておらず、最小のHobbyプラン（月12ドル）を契約したうえで検証する形になります。サーバ代は別途プロバイダへ支払いますが、Laravel VPSを使う場合は稼働時間に応じた課金で、1時間単位に丸められます。検証だけなら小さめのサーバを立てて数時間で削除する運用でも費用は抑えられるでしょう。

Laravelを使っていないアプリでも動かせますか？

Laravel以外のアプリも動作対象です。素のPHPアプリ、WordPress、Statamic、静的なHTMLページに加えて、Node.js・Nuxt・Next.jsのアプリにも対応しています。ただしPHP以外のスタックは現時点では手作業での設定が前提になる部分が残り、公式も対応言語の拡大を今後の課題として挙げています。

ForgeとLaravel Cloudはどちらを選ぶべきですか？

サーバの所有と請求を顧客側に残す必要があるか、OS層へ手を入れる要件があるか、非Laravelのアプリを同居させるかの3点で判断してください。いずれかに当てはまるならForge、どれにも当てはまらず運用の手離れを優先したいならCloudが噛み合います。費用の性格も、Forgeは定額で読みやすく、Cloudは使わない時間の費用が消える形で異なります。

ゼロダウンタイムを既存サイトへ後から追加できますか？

できません。この機能はサイトの新規作成時にのみ設定でき、後から有効化する経路は公式に用意されていない仕様です。既存サイトを切り替えるなら、同じサーバ上にゼロダウンタイムを有効にした新しいサイトを作り、ドキュメントルートとドメインを付け替える手順になります。作業前に共有パスと環境変数の移送を確認してください。

デプロイが10分を超えて失敗する場合はどうしますか？

Forgeのデプロイには10分の上限があり、超えると自動で失敗扱いです。多くはフロントエンドのビルドが時間を食っているため、成果物をCI側でビルドして配布物として受け渡す構成が有効です。Composerの依存解決に時間がかかる場合は、キャッシュの共有パス登録も効きます。Envoyerと連携しているサイトでは、Envoyer側の上限が適用されます。

関連記事

• Laravel Cloudとは｜構成・料金・ForgeとVaporの違いと受託での採用条件：サーバを持たない側の構成と従量料金を扱っています。
• Laravel Octaneとは｜ワーカー常駐の仕組みと状態リーク・採用条件：ゼロダウンタイムと併用しない理由の背景です。
• Laravel Sailとは｜sail up・sail downなど基本コマンドの使い方と導入手順：ローカル環境をコンテナで組む手順です。
• Laravel Herdとは｜PHPバージョン切替と.test公開の仕組み・Sailとの使い分け：ローカル環境のもう一方の選択肢です。
• Laravelの将来性を2026年のデータで判断する｜サポート期限・求人単価・AI対応：採用判断の前提になる材料です。