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.
- 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?