Skip to content(if available)orjump to list(if available)

Laravel Cloud

Laravel Cloud

76 comments

·February 24, 2025

danpalmer

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?

jbreckmckye

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

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.

echelon

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.

liveoneggs

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/

jacobyoder

forge is really just cloud provisioning, not the hosting/execution directly. and... shout out to ploi.io, a forge competitor doing good work.

martin_drapeau

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.

wesselbindt

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.

tallowen

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

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

ZYbCRq22HbJ2y7

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

carlos-menezes

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

slt2021

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

wesselbindt

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?

ZYbCRq22HbJ2y7

You don't think your customers are paying for performance and uptime?

osigurdson

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.

slt2021

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

To be frank - no. Systems with horrendous performance and uptime still tend to sell perfectly well. Especially when your customers are enterprise users.

thecodemonkey

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.

ZYbCRq22HbJ2y7

Why would the deployment process be faster than anything else?

Why Laravel cloud over anything else?

null

[deleted]

tnolet

Kinda annoying I have to put in a CC before starting a free $0 plan.

mylonov

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.

tnolet

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.

jay-barronville

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

jtwaleson

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!

pier25

So apps autosleep after a certain time.

How long does it take for an app to wake up?

Is this using firecracker like Fly?

lowercased

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?

pier25

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/

jppope

Congrats on the release. I'm interested to see how the project goes.

MassiveQuasar

Why do I need an account to view the docs?

joelennon

Works for me without signing in https://cloud.laravel.com/docs/intro

nik736

Where is it hosted at?

null

[deleted]

conradfr

I'm still not sure why anybody would use Laravel instead of Symfony but Taylor Otwell bank account proves I'm apparently stupid.

code_runner

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

throitallaway

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.

rokkamokka

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?

conradfr

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.

gregrobson

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.

vednig

That's a nice one

Dachande663

-

theonething

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.