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.
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.
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.
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.
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.
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).
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)
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.
To be frank - no. Systems with horrendous performance and uptime still tend to sell perfectly well. Especially when your customers are enterprise users.
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 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.
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.
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.
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.
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.
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.
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.
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!
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.
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?
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.
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.
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
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.
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.
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.
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.
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.
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.
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/
> 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.
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.
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).
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)
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.
To be frank - no. Systems with horrendous performance and uptime still tend to sell perfectly well. Especially when your customers are enterprise users.
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.
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.
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.
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.
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.
It was strictly RoR for a long time
They were Ruby only for years...
Like, we had Rails and could deploy to Heroku before Nodejs even existed...
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]
You've got to start somewhere :)
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.
> 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 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.
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?
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.
So you get AWS-pwned on your bill after 10Gb?
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.
$20 is too high for small sites and hobby projects that wish to use custom domains.
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!
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
like cockroaches, PHP will be around long after humanity dies out
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
Why do I need an account to view the docs?
Works for me without signing in https://cloud.laravel.com/docs/intro
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.
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.
Laravel started out as a PHP Rails-clone, no?
> 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.
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.
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.
congrats!
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
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.
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.
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.
Why would anyone use Symfony instead of Laravel?
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.