I'm surprised that there are new language specific hosting services like this cropping up. It just seems like the wrong level of abstraction, particularly for frameworks like this. Infrastructure makes sense at a few levels of abstraction...
- 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?
No, I see it the other way. This is a great business model and potentially product too.
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.
Sounds like a great way to get locked into paying for more than you need.
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.
I disagree, at least in this specific context. With Laravel Cloud you build a standard Laravel application which can be deployed anywhere, then use the service to handle DevOps for you. Because it doesn't include any unique services of its own, you can always decide to hire a DevOps team and run all the required services yourself.
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.
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
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?
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.
You’re conveniently ignoring the fact that these same people earn money with what they are doing, despite their not-really-knowing, so that seems like a better business strategy than elitism in an online forum to me.
It is not elitism. It is a fact that all framework user bases have these type of users. Some call them newbies.
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?
Fundamentally it’s just infra reselling as well, with some additional lock-in for that sweet retention.
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.
Well no, but chuck your app in a container and you've got something that'll run just fine on ec2 or a dozen other language agnostic platforms. What is the value add of restricting the framework you can use for your app?
The "chuck your app in a container" is doing some very, very heavy lifting here. Deployment of a full blown laravel app isn't three lines of docker config.
I admit, I actually don't know much about the php ecosystem. I just extrapolated what I know about the python web app ecosystem, and that's probably not entirely fair.
I think a lot of customers take it for granted and expect stuff to "just work".
If they pay for laravel site - they expect it to work, and don't expect to pay for keeping stuff running for the stuff they paid already (feature development + cloud bill)
To be frank - no. Systems with horrendous performance and uptime still tend to sell perfectly well. Especially when your customers are enterprise users.
It is kind of an odd chasm. Users care about and pay for pixels. Sometimes decision makers care about underlying technologies as they don't actually interact with the pixels (e.g. SAP).
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.
There are a bunch of things that still are language or language architecture specific.
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!
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).
That's not incompatible with my point though. I'd actually argue that pushing a Docker image is easier than pushing a raw codebase and having to figure out annoying build issues where your local environment differs from production – I've debugged that on Heroku in the past and it's a pain, but much less of a problem with Docker.
Shipping a laravel image means shipping an image that does queues and an image that does web serving. There's a ton of complexity in that when you have to start scaling your queues independent of your web services.
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.
Exactly. What happens when a project outgrows Laravel in some particular way.
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.
The PHP community in particular seems to gravitate toward these specialized hosts I have noticed.
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.
That’s funny, because Rails is the one big framework that does not have a framework level hosting provider. Wordpress has it, Nextjs has it and now Laravel has it. There is no Rails equivalent.
Yeah, I’m very familiar with them. But they never really were a framework specific platform or at least did not go in that direction very long. Now they are explicitly a framework agnostic PaaS.
being language or framework specific is not make sense either, do you rather have bussiness that tied to 1 framework userbase vs multiple framework supported platform????
Not really. While I prefer rails’ stance of “you can’t pay me for my open source”, laravel having a commercial model around developer tooling made them at least more responsive to their community’s dx wishes.
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.
I'm not a php guy, or a MVC guy, or really anything in their ecosystem... but I will say Taylor Otwell and his team do an amazing job at their little slice of the developer world. Again, not my cup of tea but we need to give credit where credit is due, they are doing a great job. "unmatched" is hyperbole obv, but the sentiment is fair
I don't know if I agree with GP but this is a subjective claim, no? You can pull out a bunch of metrics by which Laravel surpasses other frameworks, and some where they don't, but the call is going to either side by licking a thumb and sticking it in the air.
The sense I'm getting from the replies to your comment is that this product is targeting that segment of the engineering community that knows how to write Laravel apps, but is somehow unable to run Laravel apps.
It makes perfect sense for Laravel specifically, because both the framework itself and the entire ecosystem around it are aimed at the kind of developer who just wants to ship the minimum viable product as fast as humanly possible, without any regard for things like long-term maintenance, vendor lock-in, infrastructure costs, etc.
I was a Laravel user for years and I was a speaker at the very first Laracon in 2013. Although I don’t really use PHP/Laravel professionally anymore (with the exception of a project at my job a couple years ago, a few personal projects over the past 5 years, and a project I maintain every now and then for an old client), every time I look at all of the progress Taylor Otwell and the team have made over the years (without sacrificing the experience or ecosystem) while elevating the PHP ecosystem along with them, I’m just in awe.
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.
Really excited for this! Had the opportunity to take part in early access over the last few weeks and the deployment process has been super smooth and insanely fast.
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.
Very interesting to see Laravel pivot to this direction (VC-backed cloud deployment and hosting solution) while Rails pivots the other way (Kamal deploy with bring-your-own cloud/provider/server).
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 think we need another year or two to see how this pans out. Supposedly the Laravel team has features for Forge on their roadmap.
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.
This looks similar to WP Cloud. It provides WordPress as a service. Its one level higher abstraction than Laravel - Laravel is a framework, WordPress is an app. Though some say WordPress is now a website framework...
Laravel is unique in that it has always had a lot of paid services based around it. There are a lot compared to other frameworks. If you go to Laravel's page you can see them all. One of my teams was using Forge and Envoyer probably 10 years ago.
And nobody complains because they are completely optional and Taylor Otwell's team puts so much effort into the framework.
There are a couple of reasons but I can cite a few, I tried to push for PaaS and failed the hard way:
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.
We need more standardization in the software world so that we can reason about how the systems work. Laravel and this new offering are a great example of that. Bravo!
The intro video mentioned the serverless databases take about 200ms to wake from hibernation. No idea on app workers, but... I would think it's within that ballpark... ? Might also depend on the app server class you're using?
Great! This is just another option. I still brew my own hosting for Laravel sites for the sake of manageability and security. For most people who do not have that infrastructure skill set these cloud options give them freedom from being forced to create their one IaC and deployment pipelines. This lets Laravel startups get further along. Honestly I foresee Laravel based sites displacing the WordPress space, it will only be a matter of time before services like GoDaddy and Bluehost offer Laravel hosting options.
Would you be willing to share what went wrong with your experience of Laravel? I haven't used it for over 5 years, but it was pretty pleasant when I did.
in my experience, symfony looked like a massive, old, gross, enterprisy solution... laravel got as far out of my way as it could and had absolutely unbelievable documentation.
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
Yes, and at this point Laravel has a healthy ecosystem built up around it. There's a large community, tons of plugins available, and professional support for it.
If there’s one thing I hate about Laravel, it’s the docs. Some things are documented, arbitrary others aren’t; many APIs offer multiple aliases or equivalent ways to solve the same problem, and the docs use them interchangeably. Sometimes there’s multiple paragraphs for an obvious feature, but a single sentence for something complicated, and you’ll have to try for yourself to find out how it behaves.
It's been interesting seeing several comments like this in the comments, since Laravel's docs may be one of the most highly-praised aspects of the framework. I suspect the divide may be that newer developers get everything they need explained in the docs in clear language, but the more advanced stuff requires some digging.
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.
That’s fair in certain parts. I like the balance they struck (at the time at least) of not super in the weeds but not high level tutorial mode. A few things around their orm specifically were a little confusing or sparse at times if memory serves
I personally haven't used "raw" Symfony but maintain a largeish Laravel application and I like almost everything about Laravel. Great documentation, good developer experience, big ecosystem.
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.
Im a PHP dev and used both extensively and I would say both frameworks are great in their own ways, Laravel is geared more towards beginners / ease and speed of development since there is more handholding and “magic” stuff, whilst Symfony feels more “formal” and is used in larger projects.
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.
Taylor has said he’s not against supporting other frameworks/apps if there is demand. Symfony and Statamic are ones I’ve seen mentioned a few times. Wouldn’t be surprised if they appear in the medium term future.
Becaus while Symfony seemed to be "the right way to do it", Laravel focused on DX and the ecosystem and was still performant enough to start a business and scale it.
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).
I'm surprised that there are new language specific hosting services like this cropping up. It just seems like the wrong level of abstraction, particularly for frameworks like this. Infrastructure makes sense at a few levels of abstraction...
- 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?
No, I see it the other way. This is a great business model and potentially product too.
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.
Sounds like a great way to get locked into paying for more than you need.
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.
I disagree, at least in this specific context. With Laravel Cloud you build a standard Laravel application which can be deployed anywhere, then use the service to handle DevOps for you. Because it doesn't include any unique services of its own, you can always decide to hire a DevOps team and run all the required services yourself.
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.
true, don't listen to these guys lol
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
Could not agree more.
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.
May I ask how Hypership differs from Vercel etc?
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?
I see Laravel Cloud as devops as a service.
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.
This is actually a 3rd option for laravel. I assume they are making money to support the project by offering these curated cloud deployment offerings.
https://vapor.laravel.com/
https://forge.laravel.com/
https://app.laravel.cloud/
forge is really just cloud provisioning, not the hosting/execution directly. and... shout out to ploi.io, a forge competitor doing good work.
https://www.amezmo.com/
It is a way for Laravel to monetize to their user base of people who don't really know what they are doing.
You’re conveniently ignoring the fact that these same people earn money with what they are doing, despite their not-really-knowing, so that seems like a better business strategy than elitism in an online forum to me.
It is not elitism. It is a fact that all framework user bases have these type of users. Some call them newbies.
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?
> I'm surprised that there are new language specific hosting services like this cropping up.
I think they look at Vercel and see they're making a good buck with similar offering.
Fundamentally it’s just infra reselling as well, with some additional lock-in for that sweet retention.
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.
think from a perspective of laravel developer: your customer pays for delivered features, not for platform engineering/SRE/devops type of stuff
Well no, but chuck your app in a container and you've got something that'll run just fine on ec2 or a dozen other language agnostic platforms. What is the value add of restricting the framework you can use for your app?
The "chuck your app in a container" is doing some very, very heavy lifting here. Deployment of a full blown laravel app isn't three lines of docker config.
I admit, I actually don't know much about the php ecosystem. I just extrapolated what I know about the python web app ecosystem, and that's probably not entirely fair.
You don't think your customers are paying for performance and uptime?
I think a lot of customers take it for granted and expect stuff to "just work". If they pay for laravel site - they expect it to work, and don't expect to pay for keeping stuff running for the stuff they paid already (feature development + cloud bill)
To be frank - no. Systems with horrendous performance and uptime still tend to sell perfectly well. Especially when your customers are enterprise users.
It is kind of an odd chasm. Users care about and pay for pixels. Sometimes decision makers care about underlying technologies as they don't actually interact with the pixels (e.g. SAP).
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 is kind of an odd chasm.
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.
>> your customer pays for delivered features
I was responding to this comment in a general sense, not weather or not to use managed services.
There are a bunch of things that still are language or language architecture specific.
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!
> Traditionally, PHP/Ruby/Python have had a process per request model
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).
Small teams don't want to bother with hosting apps. Shipping features equals money.
That's not incompatible with my point though. I'd actually argue that pushing a Docker image is easier than pushing a raw codebase and having to figure out annoying build issues where your local environment differs from production – I've debugged that on Heroku in the past and it's a pain, but much less of a problem with Docker.
Shipping a laravel image means shipping an image that does queues and an image that does web serving. There's a ton of complexity in that when you have to start scaling your queues independent of your web services.
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.
Easier to who? The audience here is folks that don’t want to wade into the murky Docker waters
> language specific
Framework-specific in this case... beyond just language-specific.
Exactly. What happens when a project outgrows Laravel in some particular way.
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.
The PHP community in particular seems to gravitate toward these specialized hosts I have noticed.
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.
The PHP and Wordpress communities are so far apart, they might just as well be different languages altogether.
I would rather think this was a pattern prevalent in the JavaScript Community, given projects like Deno or Vercel.
The Laravel developer ecosystem is unmatched.
The Ruby on Rails community had stuff like this what, 18 years ago?
That’s funny, because Rails is the one big framework that does not have a framework level hosting provider. Wordpress has it, Nextjs has it and now Laravel has it. There is no Rails equivalent.
Did you forget about Heroku? It started life as a Ruby and Rails hosting provider in what, 2007?
Yeah, I’m very familiar with them. But they never really were a framework specific platform or at least did not go in that direction very long. Now they are explicitly a framework agnostic PaaS.
They were Ruby only for years...
Like, we had Rails and could deploy to Heroku before Nodejs even existed...
It was strictly RoR for a long time
being language or framework specific is not make sense either, do you rather have bussiness that tied to 1 framework userbase vs multiple framework supported platform????
like its no brainer
Not really. While I prefer rails’ stance of “you can’t pay me for my open source”, laravel having a commercial model around developer tooling made them at least more responsive to their community’s dx wishes.
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.
[flagged]
I'm not a php guy, or a MVC guy, or really anything in their ecosystem... but I will say Taylor Otwell and his team do an amazing job at their little slice of the developer world. Again, not my cup of tea but we need to give credit where credit is due, they are doing a great job. "unmatched" is hyperbole obv, but the sentiment is fair
You are right that my comment could have been more helpful.
My reply and point is Laravel has grown far beyond a simple PHP Framework.
The entire ecosystem of various Laravel related tools can solve a majority of problems for developers and businesses.
> easily calculate whether this is true or not
I don't know if I agree with GP but this is a subjective claim, no? You can pull out a bunch of metrics by which Laravel surpasses other frameworks, and some where they don't, but the call is going to either side by licking a thumb and sticking it in the air.
What is your calculation?
[flagged]
The sense I'm getting from the replies to your comment is that this product is targeting that segment of the engineering community that knows how to write Laravel apps, but is somehow unable to run Laravel apps.
> I'm surprised that there are new language specific hosting services like this cropping up.
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.
It's library specific rather than language specific.
It's also very common, especially for Wordpress and PHP/MariaDB. If you want cheap no-nonsense hosting it's a good starting option.
You've got to start somewhere :)
You do understand that there are a lot of smaller ecosystems out there right?
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
Vercel
It makes perfect sense for Laravel specifically, because both the framework itself and the entire ecosystem around it are aimed at the kind of developer who just wants to ship the minimum viable product as fast as humanly possible, without any regard for things like long-term maintenance, vendor lock-in, infrastructure costs, etc.
I was a Laravel user for years and I was a speaker at the very first Laracon in 2013. Although I don’t really use PHP/Laravel professionally anymore (with the exception of a project at my job a couple years ago, a few personal projects over the past 5 years, and a project I maintain every now and then for an old client), every time I look at all of the progress Taylor Otwell and the team have made over the years (without sacrificing the experience or ecosystem) while elevating the PHP ecosystem along with them, I’m just in awe.
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!
[0]: https://news.ycombinator.com/item?id=38596346
Really excited for this! Had the opportunity to take part in early access over the last few weeks and the deployment process has been super smooth and insanely fast.
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 would the deployment process be faster than anything else?
Why Laravel cloud over anything else?
Very interesting to see Laravel pivot to this direction (VC-backed cloud deployment and hosting solution) while Rails pivots the other way (Kamal deploy with bring-your-own cloud/provider/server).
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 think we need another year or two to see how this pans out. Supposedly the Laravel team has features for Forge on their roadmap.
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.
Oh absolutely.
This looks similar to WP Cloud. It provides WordPress as a service. Its one level higher abstraction than Laravel - Laravel is a framework, WordPress is an app. Though some say WordPress is now a website framework...
https://wp.cloud
Kinda annoying I have to put in a CC before starting a free $0 plan.
Some things are free (like 10Gb traffic), but storage for example is not. So you don't pay for the account, but you need to pay for usage.
The idea is the company eats that cost and sees it as marketing. It’s pretty common with dev tools. But not required of course.
So you get AWS-pwned on your bill after 10Gb?
it's $240 per year for an app in production, plus $6 for the domain plus compute costs.
with that money you can pay claude to dockerize and deploy to a vps
This is a clone of Amezmo, which started in 2019.
I see they ripped off every feature that we innovated.
It’s actually quite flattering.
Why are cloud based open source things working now but failed the first time Heroku came around ?
Laravel is unique in that it has always had a lot of paid services based around it. There are a lot compared to other frameworks. If you go to Laravel's page you can see them all. One of my teams was using Forge and Envoyer probably 10 years ago.
And nobody complains because they are completely optional and Taylor Otwell's team puts so much effort into the framework.
> And nobody complains because they are completely optional and Taylor Otwell's team puts so much effort into the framework.
And the team also dogfoods heavily.
Laravel has excellent DX because the people building it use it to build those products.
Laravel started out as a PHP Rails-clone, no?
correct
It like Wordpress but without the drama.
The only thing WordPress and Laravel have in common is that both are written in PHP.
But if you've used Laravel, you know it's pleasant to write apps with it.
and more lambos
There are a couple of reasons but I can cite a few, I tried to push for PaaS and failed the hard way:
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.
Annoying there's no sqlite option. Not enough money in it? Difficult?
You don’t need a separate gui config for SQLite. Just modify the env to a path on disk and send it.
Today, after some years of not using Laravel, i took a glance at their website, planing to eventually use Laravel for a small project.
I was completely shied away by their super marketing strategy and their hundreds of "super useful" packages with all their glorious names.
We need more standardization in the software world so that we can reason about how the systems work. Laravel and this new offering are a great example of that. Bravo!
So apps autosleep after a certain time.
How long does it take for an app to wake up?
Is this using firecracker like Fly?
The intro video mentioned the serverless databases take about 200ms to wake from hibernation. No idea on app workers, but... I would think it's within that ballpark... ? Might also depend on the app server class you're using?
The serverless PG is provided by Neon so it's a different infra.
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.
[1] https://firecracker-microvm.github.io/
Congrats on the release. I'm interested to see how the project goes.
Where is it hosted at?
AWS based on https://cloud.laravel.com/docs/pricing#compute
Great! This is just another option. I still brew my own hosting for Laravel sites for the sake of manageability and security. For most people who do not have that infrastructure skill set these cloud options give them freedom from being forced to create their one IaC and deployment pipelines. This lets Laravel startups get further along. Honestly I foresee Laravel based sites displacing the WordPress space, it will only be a matter of time before services like GoDaddy and Bluehost offer Laravel hosting options.
Why do I need an account to view the docs?
Works for me without signing in https://cloud.laravel.com/docs/intro
like cockroaches, PHP will be around long after humanity dies out
$20 is too high for small sites and hobby projects that wish to use custom domains.
That's a nice one
-
Would you be willing to share what went wrong with your experience of Laravel? I haven't used it for over 5 years, but it was pretty pleasant when I did.
congrats!
[dead]
I'm still not sure why anybody would use Laravel instead of Symfony but Taylor Otwell bank account proves I'm apparently stupid.
in my experience, symfony looked like a massive, old, gross, enterprisy solution... laravel got as far out of my way as it could and had absolutely unbelievable documentation.
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
Yes, and at this point Laravel has a healthy ecosystem built up around it. There's a large community, tons of plugins available, and professional support for it.
If there’s one thing I hate about Laravel, it’s the docs. Some things are documented, arbitrary others aren’t; many APIs offer multiple aliases or equivalent ways to solve the same problem, and the docs use them interchangeably. Sometimes there’s multiple paragraphs for an obvious feature, but a single sentence for something complicated, and you’ll have to try for yourself to find out how it behaves.
It's been interesting seeing several comments like this in the comments, since Laravel's docs may be one of the most highly-praised aspects of the framework. I suspect the divide may be that newer developers get everything they need explained in the docs in clear language, but the more advanced stuff requires some digging.
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.
That’s fair in certain parts. I like the balance they struck (at the time at least) of not super in the weeds but not high level tutorial mode. A few things around their orm specifically were a little confusing or sparse at times if memory serves
I personally haven't used "raw" Symfony but maintain a largeish Laravel application and I like almost everything about Laravel. Great documentation, good developer experience, big ecosystem.
Have you used both extensively and prefer "raw" Symfony?
I'm not sure what is "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.
Laravel sits on top of symfony, so with laravel you're using symfony anyway. Without laravel, you have symfony "raw".
Im a PHP dev and used both extensively and I would say both frameworks are great in their own ways, Laravel is geared more towards beginners / ease and speed of development since there is more handholding and “magic” stuff, whilst Symfony feels more “formal” and is used in larger projects.
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.
Taylor has said he’s not against supporting other frameworks/apps if there is demand. Symfony and Statamic are ones I’ve seen mentioned a few times. Wouldn’t be surprised if they appear in the medium term future.
Becaus while Symfony seemed to be "the right way to do it", Laravel focused on DX and the ecosystem and was still performant enough to start a business and scale it.
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).
Why would anyone use Symfony instead of Laravel?
Bluntly, because from a pure ecosystem and usability for new users perspective Symfony massively dropped the ball.