Originally published at hafiz.dev
The two things that kept most Laravel developers off Laravel Cloud were cost and the fear of a surprise bill. The Laravel team just announced both are being fixed, along with three other significant changes coming over the next few weeks.
Here's what was announced and what it actually means.
The Five Announcements
The announcement laid them out clearly:
1. A new $5/month plan. Previously, your options were Starter (free tier, pay-as-you-go, limited features) or Growth ($20/month). The new $5/month tier sits between them. The stated goal: "We want Cloud to be accessible to every Laravel developer."
2. Spend caps. Set a spending limit on your account. When you hit it, Cloud will either alert you or shut off compute entirely. No more anxiety about waking up to an unexpected $300 bill.
3. True scale-to-zero with 10x faster wake-up. Hibernation has existed for a while, but wake-up previously took 5-20 seconds. App, database, and cache wake-up is now measured in milliseconds. Users won't notice it.
4. Bot protection rules. Keeps hibernated apps dormant longer by filtering bot traffic before it wakes your environment. This directly reduces compute spend. Bots won't trigger unnecessary wake-ups that eat into your budget.
5. Managed queues. Queue clusters are being rebuilt into a new "managed queues" product. Set a maximum worker count and Cloud handles everything else. It scales on queue depth (not just CPU) and scales to zero when idle. No more guessing at worker sizing.
These changes aren't live yet. The announcement said "coming over the next few weeks," so treat this as a planning-ahead post rather than a same-day implementation guide.
The Spend Cap Is the Real News
The $5/month price point gets the headline, but spend caps are what actually unlocks Cloud for cautious teams.
Usage-based pricing always carries anxiety. Even with hibernation enabled, one unexpected traffic spike, a crawling bot hammering your endpoints, or a runaway job queue could turn a $10 month into an $80 one. That unpredictability kept teams on fixed-cost Forge servers where the bill was predictable even if the compute was oversized.
Spend caps change the risk profile completely. You can enable hibernation, deploy a small instance, and know that the maximum you'll pay in a worst-case month is whatever cap you set. That's a fundamentally different product than "usage-based with no ceiling."
Combine spend caps with the new bot protection rules and the hibernation economics get significantly better. Bots are the silent killers of scale-to-zero apps. They wake your environment constantly without generating real revenue. Filtering them before they trigger a wake-up means your app actually stays dormant during off-peak hours instead of yo-yoing on and off.
What Millisecond Wake-Up Changes
The previous 5-20 second cold start was the biggest practical barrier to using hibernation on anything user-facing. You could use it for staging environments and dev instances without issue, but putting a hibernating app in front of real users meant the first request after idle time got a slow response. Users noticed. Support tickets followed.
Millisecond wake-up removes that constraint. If the wake-up is imperceptible, hibernation becomes a pure cost optimization with no UX downside. You can run a production app with a low-cost Flex instance, hibernate between traffic windows, and pay only for active time, without needing a "warm-up" strategy or a cron job to keep things alive.
One question worth watching: the tweet mentions milliseconds for app, database, and cache wake-up. The database wake-up is the historically slow part. If serverless Postgres wakes in milliseconds consistently, that's a genuine infrastructure achievement. The community will stress-test this quickly once it ships.
Managed Queues as a Quiet Win
The managed queues announcement is being slightly overshadowed by the pricing news, but it's significant for teams running serious background processing.
Queue workers have always required manual tuning. How many workers does this job type need? What happens if the queue backs up? How do you prevent workers from sitting idle at 3am burning compute? The standard answer was either Horizon with careful configuration or accepting occasional over-provisioning, patterns covered in the Laravel queue jobs guide.
Managed queues take that decision away. Cloud monitors queue depth and adjusts worker count automatically. When the queue drains, workers scale to zero. When it fills, they spin up. You set a maximum and stop thinking about it.
For applications with variable job loads (processing payments, sending email campaigns, handling webhooks), this is cleaner than anything available on Forge or Vapor today. It ties directly into the monitoring and observability improvements that make Cloud worth the higher base cost.
The New Math: Cloud vs Forge vs Vapor
With the new plan, the comparison looks different for small projects.
Indie developer with multiple side projects:
- Cloud (new $5 tier + usage with hibernation): $5 + ~$2-5/month per app
- Forge: $17/month base (you can add cheap VPS servers, but Forge itself is $17)
- VPS direct: $5-10/month per server (you manage everything)
One developer in the announcement thread shared they're running seven apps with decent traffic for $6/month total using scale-to-zero. That number will improve further with bot protection and millisecond cold starts. For anyone currently running multiple low-traffic side projects on separate servers, the Cloud math starts looking favorable.
Pre-scale startup on Growth ($20/month):
- Cloud Growth: $20/month + ~$16-25 usage = ~$36-45/month
- Forge: $17/month + $20-40/month DigitalOcean/Hetzner VPS = ~$37-57/month
At this tier, the total cost is similar, but Cloud includes autoscaling, managed databases, preview environments, and zero DevOps overhead. Forge requires you to configure servers, manage Nginx, handle SSL renewal, and tune your own scaling. The value comparison has always favoured Cloud for teams without a dedicated DevOps person. The new pricing makes it viable to reach that tier sooner.
Vapor ($39/month):
Vapor runs on AWS Lambda, which gives you true serverless with different performance characteristics. It's still the right choice for teams deeply invested in the AWS ecosystem. But for most Laravel developers who just want their app deployed and scaled without thinking about infrastructure, Cloud's model is more Laravel-native and increasingly competitive on price. The CI/CD and deployment guide from last week covers how to automate your Cloud deployments via GitHub Actions.
Who Should Be Paying Attention
Indie developers and side project builders. The $5/month plan plus spend caps makes Cloud viable for projects that previously couldn't justify $20/month. Multiple side projects on a single Cloud account with hibernation enabled could cost less than one Forge server.
Small agencies running client sites. Preview environments per pull request plus managed databases at $5-20/month per project is a clearly compelling agency workflow. The managed queues addition makes it viable for client projects with background job requirements.
Teams on Forge who don't enjoy server management. If you're paying someone to manage Forge servers (patching, monitoring, scaling), Cloud is worth a fresh look. The total cost might be similar, but the management overhead disappears. For teams building SaaS products on Laravel, the complete SaaS guide covers the broader architecture decisions where Cloud fits naturally.
Anyone who previously tried Cloud and left because of cost or cold start anxiety. Both objections are being addressed directly. Worth revisiting once the features ship.
Who Should Stay Where They Are
Developers who want full server control. Forge gives you root access and complete flexibility. Cloud abstracts that away by design. If you need custom Nginx configs, non-standard PHP extensions, or specific OS-level tooling, Forge is still the better choice.
Teams on Vapor with existing AWS infrastructure. The Lambda model suits certain workloads well and migrating away from a working setup for incremental cost savings rarely makes sense.
High-traffic, always-on applications. Hibernation economics only work when your app has genuine idle periods. If you're running a busy production app that never sleeps, the cost advantage disappears and a dedicated server (Forge or otherwise) may still be cheaper.
The Bigger Picture
The Scotty vs Envoy post from April made the case that the Laravel deployment tooling ecosystem is maturing fast. This announcement reinforces that. A $5/month managed hosting tier with spend caps and millisecond cold starts is a product that didn't exist anywhere in the PHP ecosystem six months ago.
The spend caps and bot protection show the team is listening to actual adoption blockers rather than just adding features. Those two additions together fix the core reason cautious developers stayed away.
The managed queues rebuild is the kind of unsexy infrastructure improvement that saves teams real operational hours once you're running it in production.
Once these ship, the "why not just use Forge" argument gets harder to make for most new Laravel projects.
FAQ
When are these features available?
The announcement said "coming over the next few weeks." No specific release date was given. Follow the official Laravel Cloud blog for the rollout timeline.
Will the $5/month plan include custom domains?
Not confirmed in the announcement. The current Starter (free) plan includes custom domains, so it's likely the $5 tier does too. Check the official pricing page once it's updated.
Does the spend cap pause the app or just alert you?
The announcement confirmed it will either alert you or shut off compute. The configuration details (which trigger, per-environment vs per-account) will be in the documentation once it ships.
Should I migrate existing apps before these features land?
Wait until they're live and documented before making migration decisions. The announcements are forward-looking; current Cloud behavior still applies today.
How does bot protection work with legitimate crawlers?
Specific configuration details weren't shared in the announcement. Presumably you'll be able to allowlist crawlers like Googlebot. More detail will come in the docs.
Worth Watching
These announcements move Laravel Cloud from "interesting but expensive" to "worth serious consideration for almost any new Laravel project." The spend caps alone change the risk calculation. The millisecond wake-up makes hibernation viable for production. The $5 plan removes the cost objection for small projects.
Whether this changes your deployment setup depends on where you are now. But if you wrote off Cloud six months ago, the next few weeks are worth another look.
If you're evaluating Laravel Cloud for a specific project and want to think through the numbers, get in touch.