[HN Gopher] Laravel Cloud
___________________________________________________________________
Laravel Cloud
Author : pier25
Score : 147 points
Date : 2025-02-24 15:26 UTC (7 hours ago)
(HTM) web link (app.laravel.cloud)
(TXT) w3m dump (app.laravel.cloud)
| nik736 wrote:
| Where is it hosted at?
| jspaetzel wrote:
| AWS based on https://cloud.laravel.com/docs/pricing#compute
| thecleaner wrote:
| Why are cloud based open source things working now but failed the
| first time Heroku came around ?
| leetharris wrote:
| 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.
| bberenberg wrote:
| It like Wordpress but without the drama.
| nonoesp wrote:
| 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.
| nvahalik wrote:
| > 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.
| butlike wrote:
| Laravel started out as a PHP Rails-clone, no?
| augustohp wrote:
| 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.
| thecodemonkey wrote:
| 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 wrote:
| Why would the deployment process be faster than anything else?
|
| Why Laravel cloud over anything else?
| vednig wrote:
| That's a nice one
| danpalmer wrote:
| 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 wrote:
| Small teams don't want to bother with hosting apps. Shipping
| features equals money.
| danpalmer wrote:
| 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 wrote:
| Easier to who? The audience here is folks that don't want
| to wade into the murky Docker waters
| martinsnow wrote:
| 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 wrote:
| The Laravel developer ecosystem is unmatched.
| dismalaf wrote:
| The Ruby on Rails community had stuff like this what, 18
| years ago?
| felipemesquita wrote:
| 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 wrote:
| 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 wrote:
| Did you forget about Heroku? It started life as a Ruby
| and Rails hosting provider in what, 2007?
| tnolet wrote:
| 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 wrote:
| They were Ruby only for years...
|
| Like, we had Rails and could deploy to Heroku before
| Nodejs even existed...
| butlike wrote:
| It was strictly RoR for a long time
| slt2021 wrote:
| think from a perspective of laravel developer: your customer
| pays for delivered features, not for platform
| engineering/SRE/devops type of stuff
| ZYbCRq22HbJ2y7 wrote:
| You don't think your customers are paying for performance and
| uptime?
| slt2021 wrote:
| 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 wrote:
| To be frank - no. Systems with horrendous performance and
| uptime still tend to sell perfectly well. Especially when
| your customers are enterprise users.
| osigurdson wrote:
| 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 wrote:
| > 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.
| wesselbindt wrote:
| 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?
| ahofmann wrote:
| 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.
| tallowen wrote:
| 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 wrote:
| > 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).
| bakugo wrote:
| 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 wrote:
| It is a way for Laravel to monetize to their user base of
| people who don't really know what they are doing.
| 9dev wrote:
| 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.
| liveoneggs wrote:
| 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 wrote:
| forge is really just cloud provisioning, not the
| hosting/execution directly. and... shout out to ploi.io, a
| forge competitor doing good work.
| steviedotboston wrote:
| https://www.amezmo.com/
| cess11 wrote:
| 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 wrote:
| > language specific
|
| Framework-specific in this case... beyond just language-
| specific.
| danpalmer wrote:
| 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 wrote:
| 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.
| jbreckmckye wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
| claudiodekker wrote:
| You've got to start somewhere :)
| wesselbindt wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Dachande663 wrote:
| -
| theonething wrote:
| 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.
| duk wrote:
| congrats!
| jppope wrote:
| Congrats on the release. I'm interested to see how the project
| goes.
| conradfr wrote:
| 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 wrote:
| 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 wrote:
| 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.
| 9dev wrote:
| 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.
| rokkamokka wrote:
| 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 wrote:
| 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.
| ahofmann wrote:
| Laravel sits on top of symfony, so with laravel you're
| using symfony anyway. Without laravel, you have symfony
| "raw".
| gregrobson wrote:
| 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.
| tacker2000 wrote:
| 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.
| thinkingtoilet wrote:
| Why would anyone use Symfony instead of Laravel?
| pier25 wrote:
| 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 wrote:
| 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 wrote:
| 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/
| MassiveQuasar wrote:
| Why do I need an account to view the docs?
| joelennon wrote:
| Works for me without signing in
| https://cloud.laravel.com/docs/intro
| jtwaleson wrote:
| 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!
| tnolet wrote:
| Kinda annoying I have to put in a CC before starting a free $0
| plan.
| mylonov wrote:
| 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 wrote:
| 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.
| butlike wrote:
| So you get AWS-pwned on your bill after 10Gb?
| jay-barronville wrote:
| 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
| Bilal_io wrote:
| $20 is too high for small sites and hobby projects that wish to
| use custom domains.
| fnord77 wrote:
| like cockroaches, PHP will be around long after humanity dies out
___________________________________________________________________
(page generated 2025-02-24 23:01 UTC)