メインコンテンツへスキップ

Documentation Index

Fetch the complete documentation index at: https://kawax.biz/llms.txt

Use this file to discover all available pages before exploring further.

Laravel Cloudとは

Laravel Cloud は、Laravel公式のフルマネージドPaaSです。
アプリのデプロイ、スケーリング、データベース、キャッシュ、WebSocket基盤まで、Laravel向けに統合されています。
CloudのChangelogでは、February 24, 2025Launched Laravel Cloud! と記録されています。2025年に一般提供が始まった比較的新しいサービスです。

Forgeとの違い

Laravel CloudとLaravel Forgeは、どちらもLaravel開発者向けですが、レイヤーが違います。
観点Laravel CloudLaravel Forge
立ち位置フルマネージドPaaSサーバー管理ツール
主な操作環境・リソースを選んでデプロイVPS / EC2 などをプロビジョニングして運用
インフラ管理最小限(Cloud側が管理)OS・ミドルウェア運用の責任はユーザー側
root権限なし(OSレベルの直接操作は想定しない)あり(サーバー運用を柔軟に制御可能)
「インフラを意識せずLaravelアプリを早く出す」ならCloud、
「サーバーを細かく制御したい」ならForgeが向いています。

Laravel Cloudが得意なこと

Laravel Cloudは、Laravelの実運用で使う機能をダッシュボード中心で有効化しやすい点が強みです。

Task Scheduler

Scheduled Tasks で、AppクラスタまたはWorkerクラスタに Scheduler を有効化するだけで schedule:run が毎分実行されます。

Managed Queues(マネージドキュー)

Queues では、Managed Queues が推奨されています。Laravel Cloud がキューのプロビジョニング、ワーカーの起動、スケーリングを自動で処理し、ジョブがない時はワーカー数がゼロまで下がるため、処理中だけ課金されます。
選択肢向いている用途スケーリング料金の考え方
Managed Queues本番・プレビュー・開発環境全般。まず最初に選ぶ構成キューの滞留状況に応じて自動。アイドル時はゼロまで縮退ワーカー稼働秒数 + キュー操作
Worker clusterqueue:work を自前管理したい、大きめのバックグラウンド処理CPU / メモリベースWorker cluster の通常料金
App cluster のバックグラウンドプロセス小規模開発や低頻度ジョブCPU / メモリベースApp cluster に含まれる
Managed Queues は、Webトラフィックとジョブ処理を分離しつつ、失敗ジョブのダッシュボードも使えます。
一方で databaseredis など別ドライバを自前管理したいなら Worker cluster、アプリと同じコンピュートで十分なら App cluster のバックグラウンドプロセスを使います。
1

Managed Queue を作成する

環境のインフラキャンバスダッシュボードで New Managed Queue をクリックします。
2

キュー名とワーカー設定を決める

キュー名、インスタンスサイズ、ポーリング間隔、最大ワーカー数などを設定します。
3

保存してデプロイする

設定を保存して再デプロイすると、Laravel Cloud がキューとワーカープールを自動で用意します。
ジョブがない時は Managed Queues のワーカーがゼロまで下がるため、後述の Scale to Zero と組み合わせた構成と相性が良いです。App cluster 側を眠らせても、キュー処理だけ必要な時に自動で起動できます。

Scale to Zero(Flex コンピュート)

Compute にある Flex は、低コストで柔軟に使える compute class です。新しい Scale to Zero は、この Flex コンピュートを旧 Hibernation から発展させた仕組みです。新しい Flex コンピュート では、HTTP リクエスト到着時の起動が 500ms 未満 まで短縮され、従来の 5〜20 秒待つ前提ではなくなりました。 有効化は App cluster の設定画面で Scale to Zero トグルをオンにし、保存後に再デプロイするだけです。 さらに、Scale to Zero が有効な環境では、スリープ中でも Scheduled Tasks とキュー処理のために環境が自動起動します。
App cluster 上で schedule:run を回しつつ、ジョブ処理は Managed Queues に任せる構成が、現在の公式ドキュメントでも最も扱いやすい組み合わせです。
App cluster 上の自前 queue:work は sleep timeout をまたぐと中断される可能性があります。キュー処理を確実に続けたいなら、公式ドキュメント通り Managed Queues を優先してください。

Laravel Octane

ComputeUse Octane as runtime を有効化すると、CloudがOctane + FrankenPHP構成で実行します。サーバー設定を手で組み立てる必要がありません。

Inertia SSR

ComputeUse Inertia SSR を有効化して使えます。スターターキットを使う場合は npm run build:ssr が推奨されています。

WebSocketサーバー(Reverb)

Laravel Cloud WebSockets で、ReverbベースのWebSocketクラスタを作成できます。環境にアタッチすると REVERB_*VITE_REVERB_* が自動注入されます。

Laravel Nightwatch連携

Environments にはワンクリック連携があり、CloudのChangelogでも July 1, 2025One-Click Nightwatch Integration が記録されています。
手動構成が必要な場合も nightwatch-on-cloud に手順があります。

料金と無料プラン

Laravel Cloudの料金は、基本的にプラン料金 + 使用量課金です。
詳細は常に Pricing を確認してください。
  • Starter: 月額 $5。毎月 $5 分の使用クレジット付き。新規サインアップは初月無料
  • Growth: $20/mo + usage、毎月 $5 分の使用クレジット付き
  • Business: $200/mo + usage、毎月 $5 分の使用クレジット付き
以前よりも Starter で小規模プロジェクトを始めやすくなりました。
Scale to Zero と Managed Queues を組み合わせると、待機時間が長い個人開発や社内ツールでもコストを読みやすくなります。

実際に使う際の注意点

root権限前提の運用はできない

CloudはPaaSなので、OSレベルの自由度より運用の簡便さを優先します。
カーネル設定や独自デーモンの常駐など、root権限前提の作業が必要ならForgeなどの選択肢を検討します。

Nightwatchのイベント量は最初に制御する

無料枠や小規模構成でNightwatchを使う場合、イベント量が増えやすいため最初にサンプリング調整を入れるのが安全です。
NIGHTWATCH_REQUEST_SAMPLE_RATE=0.1
NIGHTWATCH_IGNORE_QUERIES=true

向いているプロジェクト・向いていないプロジェクト

向いている

  • Laravelアプリを最短で本番投入したい
  • Scheduler / Queue / Octane / Inertia SSR / Reverb をまとめて運用したい
  • アプリ開発に集中し、サーバー運用コストを下げたい

向いていない

  • root権限でOSレベルまで強くチューニングしたい
  • 既存の特殊インフラ要件(独自ミドルウェアや特殊ネットワーク制約)が強い

まとめ

Laravel Cloudは「Laravelの高度な機能を、インフラ構築の負担を下げて運用したい」チームに強く向いています。
特に Scheduler / Queue / Octane / Inertia SSR / Reverb / Nightwatch を組み合わせるプロジェクトでは、立ち上げと運用の初速が大きく上がります。
一方で、root権限が必要な運用を前提にする場合はForgeのほうが適しています。
まずは無料トライアルで実際のワークロードを流し、運用要件に合うかを確認するのが確実です。
Last modified on June 2, 2026