Laravel Cloud CLI left beta with a short deployment path: install the CLI, authenticate, and run cloud ship. The terminal can manage application deployment plus related database, cache, storage, and domain resources without requiring the dashboard for the normal flow.
This closes a product-experience gap around PHP. Teams that chose Laravel often assembled server configuration, pipelines, Forge, and cloud services before the application reached users. An integrated command makes a new service feel closer to deployment workflows associated with Vercel or modern Rails platforms.
Convenience has a price curve. The Starter plan had no fixed monthly fee and could hibernate, with a small instance around five dollars per month. Growth started at twenty dollars and Business at two hundred; larger compute reached substantially higher per-instance prices. A low entry cost does not describe the bill at sustained traffic.
First ship and routine deploy are different jobs
cloud ship is a guided flow: it detects the repository, asks for region and name, and can sync .env, create a database or cache, and enable the scheduler, Octane, or WebSockets. It exists to get the app running without opening the dashboard. CLI docs separate that from cloud deploy, which resolves the application and environment from repository configuration and follows progress.
Treating both as the same shortcut hides the permanent work. Routine needs cloud repo:config (it writes application_id and organization_id to .cloud/config.json), deploy from CI, monitoring, and rollback. The CLI exposes --json and token auth for GitHub Actions and environments without a TTY. Convenience on a developer laptop is not the production contract.
Before standardizing Cloud for the team, write the path from a merge to a stable environment: who triggers deploy, what counts as health, who reverts, where logs live. If the answer is "someone runs ship again," you still have a bootstrap shortcut, not an operation.
The REST API covers what the dashboard covers. Feature-branch environments, teardown after a PR, scale-to-zero schedules, and alerts in the existing observability stack become scripts. That is the real gain for a team that already has a pipeline. The single terminal command is the front door.
A cheap plan describes entry, not the agreed bill
The pricing page lists Starter at US$5 per month plus usage (first month free and a usage credit), Growth at US$20, and Business at US$200, all plus consumption. Flex on Starter hibernates and wakes in under 500 ms. Growth adds Pro compute, autoscaling up to 10 replicas, preview environments, and team roles. Business widens autoscaling, WAF, and log retention. You can set a spend cap: alerts at 50%, 80%, and 100%, and compute pauses at the limit.
The operational spreadsheet needs three rows, not one. Plan base. Compute, database, cache, queue, and storage while awake. Cost of staying awake all month if hibernation does not apply. A SaaS with 24-hour workers does not share a profile with a site that sleeps. Comparing only the US$5 entry price with a stray VPS mixes products.
I would run the estimator on the pricing page with the product's awake hours, not the hobby scenario. Then compare Forge (you operate the server) and Vapor (Lambda and the AWS console). Cloud sells managed infrastructure on EC2. The price includes that operations work. Hiding it inside a "deploy in 30 seconds" conversation postpones the surprise to the month traffic stops being sporadic.
A spend cap prevents an unbounded invoice. It does not prevent the capacity conversation: if compute pauses at the ceiling, the product goes down. Anyone using the cap as a defense needs an alert and an owner who can raise the limit or cut replicas.
Terminal convenience does not port managed state
Leaving the platform is never the inverse of cloud ship. Managed databases, cache, buckets, domains, queues, environment variables, background processes, and WebSocket clusters stay with the provider. The CLI helps list, dump, and destroy. It does not wrap a single artifact that boots elsewhere with the same command.
Before concentrating production on Cloud, write the exit test on one page. How the database is exported. Where object storage is copied. Which DNS records point at the platform edge. Which jobs cannot lose messages during a move. If the team cannot answer that in an afternoon, exit cost is still opaque. Opacity is the lock-in, more than the missing "export account" button.
.cloud/config.json in the repository binds the project to organization IDs. That is useful day to day and it is explicit coupling. Treat it like another ecosystem's vercel.json: convenience with a fixed address. The Laravel app remains PHP code; the surrounding operation (region, instance size, hibernation, WAF) does not travel with it.
Forge still exists for teams that want the server. Vapor still exists for teams already on Lambda. Cloud's CLI does not unify those exits. It makes the managed option so easy to start that staying has to be a conscious decision.
An agent with an infra API needs a narrow permission
The API announcement is explicit that agents can provision databases, inspect replica counts, and query scale-to-zero status. The CLI can install skills for Claude, Cursor, Copilot, and generic agents. That reduces repeated work. It also widens the surface: a token with account-wide reach can create a billable resource.
Scope the token to the flow. Deploying an existing environment is one power. Creating a database cluster is another. Running cloud tinker --code against production is a third. In CI, use an organization-specific token, --json, and refuse interactive prompts. Outside CI, do not give the agent skill a production credential in the same profile as a feature laptop.
The DX gain of cloud ship is real and changes the hiring conversation around PHP. The platform decision remains sustained-load price, who may create resources, and an exit test written before traffic concentrates. Without those three, the team buys bootstrap speed and meets the rest on the invoice or in the incident.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
