Laravel Cloud vs Forge: pricing, control, and which one fits your team

Laravel ships two ways to get an app into production, and the naming does not make the choice obvious. Laravel Cloud and Laravel Forge are both first-party, both deploy from a git push, and both do zero downtime releases. What separates them is not a feature list. It is who owns the server and how you get billed. Get that distinction right and the decision takes about five minutes.

All pricing below was checked against Laravel's own pricing pages on July 24, 2026. Vendors change prices, so verify before you commit money.

What is the difference between Laravel Cloud and Forge?

Laravel Cloud is a managed hosting platform. You connect a repository, pick a region, and Laravel runs the infrastructure. You never see a server, never patch one, and never SSH into one. Databases, cache, object storage, queues, the scheduler, SSL, CDN and DDoS protection are all provisioned for you from the dashboard.

Laravel Forge is a server management panel. It does not host anything. You bring a cloud account (DigitalOcean, Hetzner, AWS, Vultr and others, or Forge's own Laravel VPS option), and Forge provisions that machine with Nginx, PHP, MySQL or Postgres, Redis and Supervisor, then manages deployments, certificates and scheduled jobs on it. The server is yours, in your account, on your provider's bill.

One correction worth making because it shows up in a lot of comparison articles: Laravel Cloud is not serverless. Laravel's own FAQ asks "Is Laravel Cloud serverless?" and answers "No. Laravel Cloud runs on dedicated AWS EC2 servers, providing predictable performance and costs." Serverless Postgres is the name of one of Cloud's database products, not a description of the platform. Laravel Vapor is the serverless one, and it runs on AWS Lambda.

Laravel Cloud vs Forge pricing compared

This is where most of the decision actually gets made, so here are both price lists side by side.

The headline numbers mislead if you read them straight across. Cloud's $5 Starter plan looks cheaper than Forge's $12 Hobby plan, but Cloud's figure is a floor with metered compute, database, cache, storage and bandwidth stacked on top, while Forge's figure is the whole Forge bill and you add a server you can price exactly. Forge is explicit about this on its pricing page: asked whether Forge is usage-based, the answer is no, it is flat-rate monthly and you pay only your subscription plus whatever your cloud provider charges.

Cloud does give you real guardrails against a runaway invoice. Every new organization gets $5 in monthly usage credits and a free first month on Starter. You can set an organization-wide monthly spending limit, you get notified at 50%, 80% and 100% of it, and compute pauses when you reach the ceiling instead of billing straight past it. That is a better safety net than most usage-based platforms offer. It is still a variable, and if you are quoting hosting to clients or running on thin margins, a variable is the thing you were trying to avoid. Teams on usage-based infrastructure generally sleep better once something is watching the spend trend and alerting mid-cycle rather than discovering it on the invoice.

Which is better for scaling, Laravel Cloud or Forge?

Cloud, clearly, if by scaling you mean handling traffic you did not plan for. It scales replicas horizontally based on CPU within limits you configure: up to 10x replicas on Growth, unlimited and scheduled autoscaling on Business. It also scales the other way, which is the part people underrate. The full stack sleeps after a configurable idle period and wakes in under 500 milliseconds, so an app nobody is using costs almost nothing.

Forge scales the way servers have always scaled: you resize the box, or you add another one and put a load balancer in front. That is deliberate and it is not a flaw, it is just manual. You decide when capacity changes, which means no surprise bill and no surprise capacity either.

The honest test is how many hours a month your app is actually awake. A staging environment, an internal tool used in business hours, or a seasonal app spends most of the month idle, and scale to zero is worth real money there. A production SaaS with paying customers, queue workers grinding through jobs overnight and a scheduler firing every minute is awake all 730 hours. Metered compute for a machine that never sleeps rarely beats a right-sized server you rent flat.

Do both support zero downtime deployments?

Yes, and this used to be the big differentiator. It is not anymore. Cloud has always deployed without downtime. Forge now includes zero downtime deployments in all new subscriptions, which absorbed what used to be a separate Laravel Envoyer product.

There is one limit worth knowing. Forge's included zero downtime deployment covers a single server. Envoyer could deploy one project to multiple servers, and Forge's version cannot, so if you deploy a project across a fleet, an existing Envoyer subscription still has a job. Forge provides a migration tool for Envoyer sites, but it carries the same single-server constraint.

The mechanics are the same on either platform and on any decent panel, because zero downtime deployment is a pattern rather than a proprietary feature: build the new release in its own directory while the old one keeps serving, run migrations, health-check it, then flip a symlink in one atomic step. The part that actually breaks deploys is almost never the switch, it is the schema. Getting database migrations safe to run mid-deploy matters more than which vendor's dashboard you clicked.

What can you run on each?

Cloud runs Laravel and Symfony applications. It auto-detects Symfony and configures the runtime accordingly. That covers a lot of ground, but it is a defined set.

Forge is looser. It provisions a general Linux server, so alongside Laravel it handles vanilla PHP, WordPress, Statamic, and Node applications including Nuxt and Next. For most real teams this matters more than it sounds. The Laravel app is rarely alone: there is usually a marketing site on WordPress, a small Node service, a static docs build and a cron box. Managing those on one server beats paying for and operating a second platform.

Cloud's answer to that is that you should not want to manage them at all, and for some teams that is right. It depends on whether your estate is one application or a portfolio.

Which should you choose?

Choose Laravel Cloud if your traffic is spiky or seasonal, you spin up a lot of preview and staging environments, your app is Laravel or Symfony and nothing else, nobody on the team wants to own a server, and a variable monthly bill is acceptable. Laravel's own framing is the same: pick Cloud for a fully managed experience with no infrastructure setup or maintenance.

Choose Laravel Forge if you want a flat, quotable monthly number, you need root SSH for a system package or a profiler, you run a mix of PHP and Node applications, and you are comfortable owning a server. Laravel's framing again matches: pick Forge for full control, environment customization, and mixed application types.

Look past both if you deploy across several cloud providers at once, you need log retention beyond Cloud's 30-day Business ceiling for audit reasons, or you want one dashboard covering servers that were never going to be Laravel-shaped. That is where a general server management panel earns its place: our Laravel Cloud alternative page breaks down the flat-rate math against Cloud's metered model, and the Laravel Forge alternative page covers the multi-cloud side. If you want the wider field, the best server management panel roundup compares six of them, including where each one loses.

A quick sanity check before you commit

Whichever way you lean, run these three numbers first. How many hours a month is the app genuinely awake, including workers and the scheduler? What does an hour of your team's time cost, and how many hours a month do you currently lose to servers? What is the worst month your traffic could plausibly produce, and can you absorb that invoice?

Teams that answer "most hours, expensive time, tight margin" almost always end up happier on flat pricing. Teams that answer "few hours, expensive time, comfortable margin" should stay managed and stop thinking about it. Both platforms are well built, and the wrong choice here is not a disaster, it is an afternoon of migration work. Just make it deliberately rather than by reading the two headline prices across a table.