Laravel Cloud
app.laravel.cloud
app.laravel.cloud
- Servers you can run what you like on – VMs, bare metal, etc.
- Containers that you can put what you like in, but which run in some system you don't control – Kubernetes, ECS, even things like Heroku are here now.
- Language specific micro-plugins, where a small piece of code is hosted in a common server process – AWS Lambda, Cloudflare workers, all the FaaS stuff. These are sometimes language specific, but I expect them to align on WASM.
Being PHP and Laravel specific doesn't really fit any of these, it's a model that sort of existed around the early Heroku days, but seemed to lose out to first Heroku and its generic buildpack system, and then eventually to containers.
What happens when a team wants to add a little Node process for some frontend thing? Do they need to move their entire hosting? Who is the target audience of a provider like this, and perhaps more importantly, can they stay with a provider like this for very long?
Edit:
Okay so i realise typing from my phone doesn't help me get the message through i want.
So laravel apps usually works by having jobs run in a cli process that's its own thing. It's still part of the same codebase as everything else, but when you run it, that's it. You just run a queue worker.
Then you can run your application in web server mode, that's when your controllers and all the other shebang is served. Rest controllers, mvc and the other stuff.
So in a typical configuration you run your application in 2 different services. One for queues and one for web. For queues there's a simple queue worker built in but there's also a more advanced called Laravel Horizon which can scale your queue worker processes on a machine. You can deploy as many of these as you want horizontally.
Then you also control however many web servers you want to deploy.
All of this sounds very easy, but it can be quite the headache to setup and maintain. So i think Laravel cloud is a good choice for small to medium teams who just wants to ship features and not want to bother with infrastructure, until the infrastructure starts to become constly.
Still, for me, having a fully open source first party tool like kamal is much better than a commercial offering, no matter how convenient it may be.
Like, we had Rails and could deploy to Heroku before Nodejs even existed...
like its no brainer
I also think that not caring at all about the underlying stuff (particularly if approached from a standpoint of arrogance) can cause you to miss important inflection points that might make a huge difference. Of course, the opposite (e.g. arrogantly not caring about the pixels) is probably worse.
It not an odd chasm, it's a wrong (and fake) chasm.
If you bring in a bit of (proper) engineering and some common sense it's easy to determine there's a threshold under which it makes sense to pay a PAAS and above which it makes sense to pay an SRE and look at managing infrastructure yourself.
Engineering is not a matter of what side to pick and what belief-system to adopt. Engineering is essentially all about trade-offs.
I was responding to this comment in a general sense, not weather or not to use managed services.
How you do manage web servers and starting / stopping processes
Traditionally, PHP/Ruby/Python have had a process per request model but even then, how these processes are started and what memory is shared between requests is different
node.js when deployed on a server allowed one process to serve many requests through the use of the event loop but this has changed with the use AWS Lambda (one process per request) which has opened up more efficient approaches (cloudflare workers)
How do you manage database connections or other shared resources PHP and Laravel expect certain types of things (i.e. db connections) to be long running. How do you deal with scaling up/down your servers in this world?
Laravel has it's own ORM with it's own apis. Can these APIs be improved to allow things to be more easily scaled?
vercel
I think vercel has shown that a tight integration between React and Infrastructure can provide a lot of value to many types of teams. I would expect the same types of benefits could exist for laravel/php!
That's completely wrong for python/ruby (unless you're writing cgi scripts).
Regarding php, that's an assumption that's usually wrong as well.
Apache's mod_php will load the php interpreter within apache and keep it resident.
php-fpm will usually keep a number of processes around and not restart them unless you configure pm.max_requests to something above zero. See https://www.php.net/manual/en/install.fpm.configuration.php and look for 'pm.max_requests'
In my opinion the greatest tragedy of php is that most libraries and frameworks are written under the assumption that the whole environment will be thrown away and the whole process killed after the current request is served and thus that it's perfectly fine to litter the address space with garbage (and php's garbage collection is nothing fancy, really).
Php people should really start assuming the process executing their code will stay around (and that restarting processes is really an anti-pattern).
Laravel, IMO, intentionally keeps these users at a low information level. Laravel's documentation is sparse, lacking essential information about the general API. This is improving somewhat these days with phpstan promoting wider adoption of documenting types. However, you really need to walk yourself through the framework to understand it, in addition to reading the provided documentation.
Also, I am not sure the point that you are trying to make here. Is it that being willfully ignorant of what you are doing is some sort of net good as long as you can convince someone to give you money?
It's also very common, especially for Wordpress and PHP/MariaDB. If you want cheap no-nonsense hosting it's a good starting option.
Framework-specific in this case... beyond just language-specific.
I worked on a big Django project for many years. We mostly used Django in the way it was intended, but there were enough custom things (normal in a 10+ year old codebase) that a Django-specific hosting provider wouldn't have known about, and therefore wouldn't have supported. That would mean either us moving hosting to support a trivial feature, or more likely, us canning the feature because our hosting wouldn't support it.
I run a B2B SaaS on Laravel and this was a dream of mine for many years. Laravel + Vuejs is sufficient to cover 99% of features we need to build and scale our business. I want my devs to build features, not infrastructure.
I'm looking forward to playing with Laravel Cloud and do hope we can migrate our production environment to it one day.
A fully integrated platform lets you sell libraries, infrastructure and support all in one package.
Rather than you configuring a Laravel storage provider to use Redis and your developer configuring infra and permissions, you could just click a checkbox in an admin panel. The service could even generate you code to act as your interface.
Rather than setting up a log provider to go to OpenTelemetry and having an exporter pipe to Datadog, you hit a button which replaces the logger in your DI stack with all the wiring handled already.
For an org that wants to move FAST it could be a really compelling product. It's also very tight vendor lock in. For some contexts, that's absolutely fine.
It's something I had an idea of doing in the NodeJS space, but I'm too wary to start my own startup. Basically designing a combined DI framework and bundling tool, then selling infrastructure adapters on top of that.
In fact, we’re tackling this exact problem with Hypership (https://hypership.dev) but in the React/Next.js and JavaScript space. Infra, auth, events, analytics, forms, database, API, everything you need to ship a product, all configurable in minutes with no glue code.
Laravel is 100% going all in on their cloud, tightly integrating their entire ecosystem. I mean, have you seen how many products they have?!
The trade-off is clear: speed vs lock-in. I'm betting on flexibility without the setup overhead. Agencies will gobble this service offering up in no time.
Coincidentally I'm currently looking for a new hoster / platform to start a new project with (probably nextjs or laravel) but having a difficult time deciding on one of the modern cloud providers like you because of the heavy vendor lock-in and hidden costs collecting in the shadows and threatening to crush my product before it can break even.
How would I prevent this from happening using e.g. Hypership?
There's a venerable history of this, from Oracle to Heroku. Solve today's problems slightly faster (minus a few days of plateng/DevOps work), and forever be exposed to having the screws tightened.
Hard pass. Infra should be commodity and replete with dozens of like kinded alternatives.
The worst offenders are those fancy JS CI/CD, one-click deploy solutions that cost 10,000x the underlying primitives. Roll your own and save yourself.
these guys have bias because that's their entire bussiness model, open source cloud deploy is the future and not tied only to laravel deployment but agnostic scalable + open source is the way
You're totally correct in scenarios where you need to build your project around the service, but this service is specifically a DevOps shortcut with no lock-in.
Should your Fortune 500 company use this? Maybe not. Should a one-man dev shop use this? Quite possibly - you pay for the convenience, but it frees up more time to improve your application.
I think they look at Vercel and see they're making a good buck with similar offering.
Back in the day every man and his dog would set up a small scale shared hosting service to put your PHP or cgi-bins on and the interface to it was basically FTP. Nowadays it’s moved on from dragging and dropping scripts to deploying integrated full-stack frameworks with a little ecosystem around it.
They aren't anything new.
Example: https://www.pythonanywhere.com/ came up in 2011.
And regarding php, php-only web hosting (php+mysql) has been a thing for like 20-25 years now.
Symfony had their own cloud, which I believe got snapped up by another niche cloud provider that was their actual IaaS platform anyway.
There's also the wordpress specific hosts, and many other platforms like this.
I'm not against or for it, per se, thats for people who are looking at the services to decide whats worth it, but I am not surprised its something being built.
I would rather think this was a pattern prevalent in the JavaScript Community, given projects like Deno or Vercel.
For people in the laravel ecosystem that might be a great thing.
Just because someone already did it or did it one way doesn't mean no one else can or should do it
I’ve said this before [0][0] and I’ll say it again: I truly admire Taylor—he’s one of those rare and brilliant humans whose contributions and work leave a personal lasting impact on you.
Congratulations on launching Laravel Cloud!
I'm mostly just impressed with how polished everything feels and how easy it was to add database, key/value store, etc.
Currently using Laravel Vapor for most of my hosting needs, but will be switching everything over to Cloud.
Why Laravel cloud over anything else?
Obviously you can still (for now, anyway) 100% run Laravel independently without Laravel cloud or any of the optional paid Laravel features. But you don't have to squint too hard to see the Laravel core team starting to prioritize features that benefit Laravel Cloud and then slowly start building Laravel Cloud-only features. Especially as VC demands larger returns.
I have a lot of respect for Taylor Otwell and I am happy he's found a way to continue to monetize his life's work, but I hope they're able to find a sustainable balance between free/open source work and paid/proprietary work.
I’ve listened to quite a few podcasts with Taylor speaking on this topic and he’s very aware that the majority of Laravel devs know that hosting a PHP app is not rocket science. He wanted to built a platform that offered a substantial bump to the UX of managing servers but realizes that it will never be a solution used by companies that want to fine tune the software or do weird shit.
Given the track record of Laravel so far, I’m willing to hear them out and let them cook for a bit before casting judgement. Taylor has also said he’s not in it for the money but only time will tell if he can hold onto that ideal as time marches forward.
with that money you can pay claude to dockerize and deploy to a vps
And nobody complains because they are completely optional and Taylor Otwell's team puts so much effort into the framework.
But if you've used Laravel, you know it's pleasant to write apps with it.
And the team also dogfoods heavily.
Laravel has excellent DX because the people building it use it to build those products.
1. No widespread practice of environment provisioning automation. Today Docker and k8s are ubiquitous. Having a list of requirements your application needs well kept were hard to find - which Heroku needs. 2. In the same sense as above, automated deployment was not a common thing. 3. Barriers to cloud adoption. Development tools were not widespread. Paying for software development and deployment is common now, it wasn't.
I see they ripped off every feature that we innovated.
It’s actually quite flattering.
I was completely shied away by their super marketing strategy and their hundreds of "super useful" packages with all their glorious names.
How long does it take for an app to wake up?
Is this using firecracker like Fly?
Fly.io uses Firecracker[1] and it's usually pretty fast.
Of course it will depend on app size etc but it's weird there's zero information about app start up time, cold starts, etc.
I am not a php person, but was on a php project and we were trying to run absolutely as fast as we could.... and laravel let us do that very effectively. If i was a php greybeard or something maybe I would've preferred symfony... but looking at our legacy symphony system compared to the laravel system we stood up and replace it.... I cannot imagine making a different choice
I use Laravel personally, and I've definitely seen both sides of this myself. For basic "happy-path" API reference, the docs are great. If I really need to understand how the framework is doing something, I pretty much always end up diving into the code. Unfortunately the heavy use of Facades can sometimes make it annoying to find the underlying code.
Have you used both extensively and prefer "raw" Symfony?
But I also think the Symfony documentation is probably the best documentation I've ever used (programming the web since the 90s) with fantastic DX so to each their own, after all competition is good.
Also, i feel Laravel is used more in the US and Symfony more in Europe.
So its really a preference thing here, you cant really go wrong either way.
There is just more attraction for things that make it easy for people to work with / build stuff, for that very reason RoR is still a big thing in 2025 and if you look at Java, people are still using Spring Boot while there are interesting competitors who may have an edge in performance and some other aspects (e.g. Quarkus).