> ## 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専用PaaSの全貌

> 2025年に登場したLaravel Cloud。Forgeとの違い、得意なこと・苦手なこと、実際に使うメリットを解説する。

## Laravel Cloudとは

[Laravel Cloud](https://cloud.laravel.com/docs/intro) は、Laravel公式の**フルマネージドPaaS**です。\
アプリのデプロイ、スケーリング、データベース、キャッシュ、WebSocket基盤まで、Laravel向けに統合されています。

Cloudの[Changelog](https://cloud.laravel.com/docs/changelog)では、`February 24, 2025` に **Launched Laravel Cloud!** と記録されています。2025年に一般提供が始まった比較的新しいサービスです。

***

## Forgeとの違い

Laravel CloudとLaravel Forgeは、どちらもLaravel開発者向けですが、レイヤーが違います。

| 観点     | Laravel Cloud        | Laravel Forge             |
| ------ | -------------------- | ------------------------- |
| 立ち位置   | フルマネージドPaaS          | サーバー管理ツール                 |
| 主な操作   | 環境・リソースを選んでデプロイ      | VPS / EC2 などをプロビジョニングして運用 |
| インフラ管理 | 最小限（Cloud側が管理）       | OS・ミドルウェア運用の責任はユーザー側      |
| root権限 | なし（OSレベルの直接操作は想定しない） | あり（サーバー運用を柔軟に制御可能）        |

「インフラを意識せずLaravelアプリを早く出す」ならCloud、\
「サーバーを細かく制御したい」ならForgeが向いています。

***

## Laravel Cloudが得意なこと

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

### Task Scheduler

[Scheduled Tasks](https://cloud.laravel.com/docs/scheduled-tasks) で、AppクラスタまたはWorkerクラスタに **Scheduler** を有効化するだけで `schedule:run` が毎分実行されます。

### Managed Queues（マネージドキュー）

[Queues](https://cloud.laravel.com/docs/queues) では、**Managed Queues** が推奨されています。Laravel Cloud がキューのプロビジョニング、ワーカーの起動、スケーリングを自動で処理し、ジョブがない時はワーカー数がゼロまで下がるため、処理中だけ課金されます。

| 選択肢                           | 向いている用途                              | スケーリング                      | 料金の考え方               |
| ----------------------------- | ------------------------------------ | --------------------------- | -------------------- |
| **Managed Queues**            | 本番・プレビュー・開発環境全般。まず最初に選ぶ構成            | キューの滞留状況に応じて自動。アイドル時はゼロまで縮退 | ワーカー稼働秒数 + キュー操作     |
| **Worker cluster**            | `queue:work` を自前管理したい、大きめのバックグラウンド処理 | CPU / メモリベース                | Worker cluster の通常料金 |
| **App cluster のバックグラウンドプロセス** | 小規模開発や低頻度ジョブ                         | CPU / メモリベース                | App cluster に含まれる    |

Managed Queues は、Webトラフィックとジョブ処理を分離しつつ、失敗ジョブのダッシュボードも使えます。\
一方で `database` や `redis` など別ドライバを自前管理したいなら Worker cluster、アプリと同じコンピュートで十分なら App cluster のバックグラウンドプロセスを使います。

<Steps>
  <Step title="Managed Queue を作成する">
    環境のインフラキャンバスダッシュボードで **New Managed Queue** をクリックします。
  </Step>

  <Step title="キュー名とワーカー設定を決める">
    キュー名、インスタンスサイズ、ポーリング間隔、最大ワーカー数などを設定します。
  </Step>

  <Step title="保存してデプロイする">
    設定を保存して再デプロイすると、Laravel Cloud がキューとワーカープールを自動で用意します。
  </Step>
</Steps>

<Tip>
  ジョブがない時は Managed Queues のワーカーがゼロまで下がるため、後述の Scale to Zero と組み合わせた構成と相性が良いです。App cluster 側を眠らせても、キュー処理だけ必要な時に自動で起動できます。
</Tip>

### Scale to Zero（Flex コンピュート）

[Compute](https://cloud.laravel.com/docs/compute#scale-to-zero) にある **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 に任せる構成が、現在の公式ドキュメントでも最も扱いやすい組み合わせです。

<Info>
  App cluster 上の自前 `queue:work` は sleep timeout をまたぐと中断される可能性があります。キュー処理を確実に続けたいなら、公式ドキュメント通り Managed Queues を優先してください。
</Info>

### Laravel Octane

[Compute](https://cloud.laravel.com/docs/compute#laravel-octane) の **Use Octane as runtime** を有効化すると、CloudがOctane + FrankenPHP構成で実行します。サーバー設定を手で組み立てる必要がありません。

### Inertia SSR

[Compute](https://cloud.laravel.com/docs/compute#inertia-ssr) の **Use Inertia SSR** を有効化して使えます。スターターキットを使う場合は `npm run build:ssr` が推奨されています。

### WebSocketサーバー（Reverb）

[Laravel Cloud WebSockets](https://cloud.laravel.com/docs/resources/websockets) で、ReverbベースのWebSocketクラスタを作成できます。環境にアタッチすると `REVERB_*` と `VITE_REVERB_*` が自動注入されます。

### Laravel Nightwatch連携

[Environments](https://cloud.laravel.com/docs/environments#nightwatch-integration) にはワンクリック連携があり、Cloudの[Changelog](https://cloud.laravel.com/docs/changelog)でも `July 1, 2025` に **One-Click Nightwatch Integration** が記録されています。\
手動構成が必要な場合も [nightwatch-on-cloud](https://cloud.laravel.com/docs/knowledge-base/nightwatch-on-cloud) に手順があります。

***

## 料金と無料プラン

Laravel Cloudの料金は、基本的に**プラン料金 + 使用量課金**です。\
詳細は常に [Pricing](https://cloud.laravel.com/docs/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を使う場合、イベント量が増えやすいため最初にサンプリング調整を入れるのが安全です。

```ini theme={null}
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のほうが適しています。\
まずは無料トライアルで実際のワークロードを流し、運用要件に合うかを確認するのが確実です。