I've been hyped for the past year about Laravel Cloud. I migrated most of my own personal stuff to it and recently had been hoping to migrate a client's project to it.
Was mostly looking forward to us having preview environments for each PR, especially as we move towards more and more code being generated by AI.
Also for this client in particular, where we're using a 3rd party for websockets (Ably), we were excited by the prospect of being able to migrate to a managed Reverb service directly on Laravel Cloud.
Unfortunately it turned out it's not quite the right fit for us at the moment. We did a trial of running an additional staging environment for the client on Laravel Cloud, integrating it with the client's repository on GitHub so we could test out the preview environments as well.
It was very close to being suitable, but we came across a few limitations that for us are a bit of a deal breaker, so we're sticking with our current solution (running DigitalOcean's App Platform + Ably) for the foreseeable future.
What was good
Fast to setup
Point at git repo, configure a few environment vars, add DB and it pretty much works out of the box. You get a laravel.cloud domain by default so it's super quick to try out. Most people could get their Laravel projects up and running in a few minutes.
Fast to deploy
A minute after merging code into main, it was live on staging. For comparison: the existing solution takes around 5 minutes.
Pricing (mostly)
Not as cheap as hosting on a VPS and managing everything yourself, however compared to other managed platforms, the pricing was looking super competitive. And most other options we could find didn't offer easy to use preview environments (or at all). The one exception is Reverb, but we'll get to that.
What wasn't good (for us)
Super basic ability to trigger commands and inspect service state
There's no interactive shell, and no ability to connect to a running instance of the service in another manner. All you get is a single text box where you can pass a command (with php artisan prefilled).
On this project we heavily make use of our own custom artisan commands (ones that include prompts and lookups) as part of our week to week operations, and also for use in debugging (e.g. via tinker) for when we can't directly replicate an issue locally.
We attempted to see if we could deal with running single commands with everything as parameters (e.g. tinker --execute="..."), but it was just too painful and limiting.
Lots of other platforms we've looked at: heroku, digital ocean, fly.io, render, railway; all feature a way to have some sort of shell access to a running instance, so we were a little surprised to not see the ability here.
Preview environments don't preserve local state when hibernating
We initially had a good experience with the preview environments in testing, but then we quickly noticed that once an environment hibernated and came back, it had lost all local state since it initially started.
We were hoping to rely on local state in preview environments to keep costs low long term, leveraging SQLite and local file storage, as opposed to spinning up a DB cluster and external storage each time. But when a preview environment resumed we found ourselves having to manually reseed data each time by triggering a command in the panel.
This could likely be worked around if the preview environments had the ability for us to specify lifecycle scripts (e.g. on hibernate/resume) that would allow us to trigger a backup/re-seed. As it stands this made the preview environments a no go for us unless we opted to spin up extra resources.
Pricing of Reverb
Our client has a ton of infrequent users with bursts throughout the year, comparing the costs of Laravel Reverb on Laravel Cloud
With Ably
For our client's traffic, mostly direct messages and targeted notifications, estimated usage with Ably is still low even after including the $29/month base fee.
Example scenario: 5,000 concurrent users online for 6 hours a month and 100 messages per user per month, the usage works out to about $33.30/month. By comparison, Laravel Cloud Reverb’s published 5,000 concurrent connections tier is $200/month.
| Scenario | Assumptions | Ably | Laravel Cloud Reverb |
|---|---|---|---|
| Base plan | Production usage | $29.00/month | — |
| Connections | 5,000 concurrent users × 6 hours/month = 1,800,000 connection-minutes | ~$1.80 | $200.00/month |
| Messages | 100 messages × 5,000 users = 500,000 published messages/month; 1 recipient per message = ~1,000,000 consumed messages total | ~$2.50 | Included in tier pricing |
| Total | ~$33.30/month | $200.00/month |
Note that if you go above 10k concurrent connections, Ably's next plan is $399(!) which includes up to 50k concurrent connections. Above 5k concurrent connections on Laravel Cloud requires contacting sales. At those stages, it's likely worth considering self hosting Reverb, or an equivalent WebSocket service.
Conclusion
Overall, close but not quite there for us yet. It's a solid platform and the speed of setup and deployment alone makes it worth considering for a lot of projects. For this project though, the shell access and preview environment limitations rule it out currently.