4 ms·

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 f

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?

martinsnow 2y ago
Small teams don't want to bother with hosting apps. Shipping features equals money.
- danpalmer 2y ago
  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.
  - tnolet 2y ago
    Easier to who? The audience here is folks that don’t want to wade into the murky Docker waters
  - martinsnow 2y ago
    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.
TIPSIO 2y ago
The Laravel developer ecosystem is unmatched.
- dismalaf 2y ago
  The Ruby on Rails community had stuff like this what, 18 years ago?
  - felipemesquita 2y ago
    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.
  - tnolet 2y 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.
    - dismalaf 2y ago
      Did you forget about Heroku? It started life as a Ruby and Rails hosting provider in what, 2007?
      - tnolet 2y ago
        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.
        dismalaf 2y ago
        They were Ruby only for years... Like, we had Rails and could deploy to Heroku before Nodejs even existed...
slt2021 2y ago
think from a perspective of laravel developer: your customer pays for delivered features, not for platform engineering/SRE/devops type of stuff
- ZYbCRq22HbJ2y7 2y ago
  You don't think your customers are paying for performance and uptime?
  - slt2021 2y ago
    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)
  - wavemode 2y ago
    To be frank - no. Systems with horrendous performance and uptime still tend to sell perfectly well. Especially when your customers are enterprise users.
  - osigurdson 2y ago
    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.
    - znpy 2y ago
      > 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.
tallowen 2y ago
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!
- znpy 2y ago
  > 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 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).
bakugo 2y ago
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.
ZYbCRq22HbJ2y7 2y ago
It is a way for Laravel to monetize to their user base of people who don't really know what they are doing.
- 9dev 2y ago
  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.
  - ZYbCRq22HbJ2y7 2y ago
    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?
liveoneggs 2y ago
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://vapor.laravel.com/ https://forge.laravel.com/ https://forge.laravel.com/ https://app.laravel.cloud/ https://app.laravel.cloud/
- jacobyoder 2y ago
  forge is really just cloud provisioning, not the hosting/execution directly. and... shout out to ploi.io, a forge competitor doing good work.
- steviedotboston 2y ago
  https://www.amezmo.com/ https://www.amezmo.com/
cess11 2y ago
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.
arbuge 2y ago
> language specific Framework-specific in this case... beyond just language-specific.
- danpalmer 2y ago
  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.
martin_drapeau 2y ago
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.
zero_shift 2y ago
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.
- upmostly 2y ago
  Could not agree more. In fact, we’re tackling this exact problem with Hypership (https://hypership.dev 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.
  - o1o1o1 2y ago
    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?
- echelon 2y ago
  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.
carlos-menezes 2y ago
> 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.
- ljm 2y ago
  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.
znpy 2y ago
> 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/ 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.
claudiodekker 2y ago
You've got to start somewhere :)
wesselbindt 2y ago
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.
no_wizard 2y ago
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.
- 9dev 2y ago
  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.
_alex_ 2y ago
Vercel
Dlooooloo 2y ago
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

martinsnow 2y ago

Small teams don't want to bother with hosting apps. Shipping features equals money.

danpalmer 2y ago
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.
- tnolet 2y ago
  Easier to who? The audience here is folks that don’t want to wade into the murky Docker waters
- martinsnow 2y ago
  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.

TIPSIO 2y ago

The Laravel developer ecosystem is unmatched.

dismalaf 2y ago
The Ruby on Rails community had stuff like this what, 18 years ago?
- felipemesquita 2y ago
  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.
- tnolet 2y 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.
  - dismalaf 2y ago
    Did you forget about Heroku? It started life as a Ruby and Rails hosting provider in what, 2007?
    - tnolet 2y ago
      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.
      - dismalaf 2y ago
        They were Ruby only for years... Like, we had Rails and could deploy to Heroku before Nodejs even existed...

slt2021 2y ago

think from a perspective of laravel developer: your customer pays for delivered features, not for platform engineering/SRE/devops type of stuff

ZYbCRq22HbJ2y7 2y ago
You don't think your customers are paying for performance and uptime?
- slt2021 2y ago
  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)
- wavemode 2y ago
  To be frank - no. Systems with horrendous performance and uptime still tend to sell perfectly well. Especially when your customers are enterprise users.
- osigurdson 2y ago
  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.
  - znpy 2y ago
    > 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.

tallowen 2y ago

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!

znpy 2y ago
> 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 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).

bakugo 2y ago

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.

ZYbCRq22HbJ2y7 2y ago

It is a way for Laravel to monetize to their user base of people who don't really know what they are doing.

9dev 2y ago
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.
- ZYbCRq22HbJ2y7 2y ago
  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?

liveoneggs 2y ago

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://vapor.laravel.com/ https://forge.laravel.com/ https://forge.laravel.com/ https://app.laravel.cloud/ https://app.laravel.cloud/

jacobyoder 2y ago
forge is really just cloud provisioning, not the hosting/execution directly. and... shout out to ploi.io, a forge competitor doing good work.
steviedotboston 2y ago
https://www.amezmo.com/ https://www.amezmo.com/

cess11 2y ago

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.

arbuge 2y ago

> language specific Framework-specific in this case... beyond just language-specific.

danpalmer 2y ago
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.

martin_drapeau 2y ago

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.

zero_shift 2y ago

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.

upmostly 2y ago
Could not agree more. In fact, we’re tackling this exact problem with Hypership (https://hypership.dev 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.
- o1o1o1 2y ago
  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?
echelon 2y ago
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.

carlos-menezes 2y ago

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

ljm 2y ago
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.

znpy 2y ago

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

claudiodekker 2y ago

You've got to start somewhere :)

wesselbindt 2y ago

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.

no_wizard 2y ago

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.

9dev 2y ago
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.

_alex_ 2y ago

Vercel

Dlooooloo 2y ago

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