$npx -y skills add laravel/agent-skills --skill deploying-laravel-cloudDeploys and manages Laravel applications on Laravel Cloud using the cloud CLI. Use when the user wants to deploy an app, ship to cloud, create/manage environments, databases, caches, domains, instances, background processes, check billing/usage/spend, or any Laravel Cloud infra
| 1 | # Deploying with Laravel Cloud CLI |
| 2 | |
| 3 | ## Setup |
| 4 | |
| 5 | ```sh |
| 6 | composer global require laravel/cloud-cli |
| 7 | cloud auth -n |
| 8 | ``` |
| 9 | |
| 10 | ## Commands |
| 11 | |
| 12 | Commands follow a CRUD pattern: `resource:list`, `resource:get`, `resource:create`, `resource:update`, `resource:delete`. |
| 13 | |
| 14 | Available resources: `application`, `environment`, `instance`, `database-cluster`, `database`, `cache`, `bucket`, `domain`, `websocket-cluster`, `background-process`, `command`, `deployment`. |
| 15 | |
| 16 | Some resources have additional commands (e.g., `domain:verify`, `database:open`, `instance:sizes`, `cache:types`). Discover these via `cloud -h`. |
| 17 | |
| 18 | Never hardcode command signatures. Always run `cloud <command> -h` to discover options at runtime. |
| 19 | |
| 20 | ## CLI Flags |
| 21 | |
| 22 | Always add `-n` to every command — prevents the CLI from hanging. |
| 23 | Never use `-q` or `--silent` — they suppress all output. |
| 24 | |
| 25 | Flag combos per operation: |
| 26 | - Read (`:list`, `:get`) → `--json -n` |
| 27 | - Create (`:create`) → `--json -n` |
| 28 | - Update (`:update`) → `--json -n --force` |
| 29 | - Delete (`:delete`) → `-n --force` (no `--json`) |
| 30 | - Environment variables → `-n --force` |
| 31 | - Deploy/ship → `-n` with all options passed explicitly (no `--json`) |
| 32 | |
| 33 | ## Deployment Workflow |
| 34 | |
| 35 | Determine the task and follow the matching path: |
| 36 | |
| 37 | First deploy? → `cloud ship -n` (discover options via `cloud ship -h`) |
| 38 | |
| 39 | Existing app? → |
| 40 | ```sh |
| 41 | cloud repo:config |
| 42 | cloud deploy {app_name} {environment} -n --open |
| 43 | cloud deploy:monitor -n |
| 44 | ``` |
| 45 | |
| 46 | Environment variables? → `cloud environment:variables -n --force` |
| 47 | |
| 48 | Provision infrastructure? → `cloud <resource>:create --json -n` |
| 49 | |
| 50 | Custom domain? → `cloud domain:create --json -n` then `cloud domain:verify -n` |
| 51 | |
| 52 | For multi-step operations, see [reference/checklists.md](reference/checklists.md). |
| 53 | |
| 54 | Not sure what the user needs? → ask them before running anything. |
| 55 | |
| 56 | ## When a Command Fails |
| 57 | |
| 58 | 1. Read the error output |
| 59 | 2. Check resource status with `:list --json -n` or `:get --json -n` |
| 60 | 3. Auth error? → `cloud auth -n` |
| 61 | 4. Fix the issue, re-run the command |
| 62 | 5. If the same error repeats after one fix, stop and ask the user |
| 63 | |
| 64 | Always run `cloud deploy:monitor -n` after every deploy. If it fails, show the user what went wrong before attempting a fix. |
| 65 | |
| 66 | ## Subagent Delegation |
| 67 | |
| 68 | Delegate high-output operations to subagents (using the Task tool) to keep the main context window small. Only the summary comes back — verbose output stays in the subagent's context. |
| 69 | |
| 70 | Delegate these to a subagent: |
| 71 | - `cloud deploy:monitor -n` — deployment logs can be very long |
| 72 | - `cloud deployment:get --json -n` — full deployment details |
| 73 | - `cloud <resource>:list --json -n` — listing many resources produces large JSON |
| 74 | - Fetching docs from https://cloud.laravel.com/docs/llms.txt via `WebFetch` |
| 75 | |
| 76 | Keep in the main context: |
| 77 | - Short commands like `:create`, `:delete`, `:update` — output is small |
| 78 | - `cloud deploy -n` — you need the deployment ID immediately |
| 79 | - Any command where you need the result for the next step right away |
| 80 | |
| 81 | ## Rules |
| 82 | |
| 83 | Follow exact steps: |
| 84 | - Flag selection — always use the documented combos above |
| 85 | - Deploy sequence — deploy then monitor, never skip monitoring |
| 86 | - Destructive commands — always confirm with user first, show the command and wait for approval |
| 87 | - Error loop — diagnose, fix once, ask user if it fails again |
| 88 | |
| 89 | Use your judgment: |
| 90 | - Instance sizes, regions, cluster types — ask the user if not specified |
| 91 | - Which resources to provision — based on what the user describes |
| 92 | - Order of provisioning — no strict sequence required |
| 93 | - How to present output — summarize, show raw, or extract fields based on context |
| 94 | |
| 95 | ## Remote Access |
| 96 | |
| 97 | ### Tinker (>= v0.2.0) |
| 98 | |
| 99 | Run PHP code directly in a Cloud environment: |
| 100 | |
| 101 | ```sh |
| 102 | cloud tinker {environment} --code='Your PHP code here' --timeout=60 -n |
| 103 | ``` |
| 104 | |
| 105 | - `--code` — PHP code to execute (required in non-interactive mode) |
| 106 | - `--timeout` — max seconds to wait for output (default: 60) |
| 107 | |
| 108 | The code must explicitly output results using `echo`, `dump`, or similar — expressions alone produce no output. |
| 109 | |
| 110 | Always pass `--code` and `-n` to avoid interactive prompts. |
| 111 | |
| 112 | ### Remote Commands |
| 113 | |
| 114 | Run shell commands on a Cloud environment: |
| 115 | |
| 116 | ```sh |
| 117 | cloud command:run {environment} --cmd='your command here' -n |
| 118 | ``` |
| 119 | |
| 120 | - `--cmd` — the command to run (required in non-interactive mode) |
| 121 | - `--no-monitor` — skip real-time output streaming |
| 122 | - `--copy-output` — copy output to clipboard |
| 123 | |
| 124 | Review past commands: |
| 125 | |
| 126 | - `cloud command:list {environment} --json -n` — list command history |
| 127 | - `cloud command:get {commandId} --json -n` — get details and output of a specific command |
| 128 | |
| 129 | Delegate `command:run` to a subagent when output may be long. |
| 130 | |
| 131 | # |