The New Laravel Forge, Nine Months Later: An Honest Review

On October 1, 2025, Laravel relaunched Forge with a complete redesign: zero-downtime deployments turned on by default, per-domain SSL, health checks from three regions, a new Organizations model for teams, and a first-party hosting option called Laravel VPS starting at $6/month with sub-10-second provisioning.

That was nine months ago. The launch-week hot takes have cooled, real teams have run real production workloads through it, and we can now answer the question that actually matters: did Forge 2.0 change the calculus for anyone deciding between Forge and its alternatives?

Short answer: yes, in both directions. Some of what shipped is genuinely excellent and removed long-standing reasons to leave. Some of it introduced new fine print that didn't exist before. This post walks through both, and we'll be upfront: we build Deploynix, a Forge alternative. That makes it more important, not less, that this assessment gives Forge real credit where it's earned. Judge for yourself whether it does.

What Forge 2.0 Actually Shipped

The relaunch wasn't a facelift. Laravel rebuilt the product, and the headline changes were substantial:

• Zero-downtime deployments by default. Every new site deploys atomically, no configuration required.

• A full UI redesign. The new interface is noticeably faster and better organized than old Forge's page-per-setting sprawl.

• Laravel VPS. Servers hosted on Laravel's own infrastructure, from $6/month, provisioned in under 10 seconds, with no cloud provider account needed.

• Per-domain SSL. Certificates are managed per domain rather than per site, which cleans up multi-domain setups considerably.

• Health checks from three regions. Built-in HTTP uptime monitoring that pings your app from multiple geographic locations.

• Organizations replacing Circles. A proper team and permissions model instead of the old server-sharing workaround.

Nine months in, all of these have held up in production. This wasn't a rushed rebrand; it was the biggest improvement to Forge since its launch.

Credit Where It's Due: Three Things Forge Got Right

Zero-Downtime by Default Was Overdue, and It's Genuinely Good

For years, a stock Forge deployment was a git pull in place followed by composer install and cache rebuilds, all against the live document root. During those seconds, requests could hit a half-updated application. You could avoid it with Envoyer (a separate subscription) or a hand-rolled deploy script, but the default was in-place mutation.

Forge 2.0 made atomic deployments the default: each deploy builds in a fresh release directory, and traffic switches over in a single symlink swap. That's the correct architecture, and making it the default rather than an upsell was the right call. If you want the mechanics of why this pattern works, including the gotchas around OPcache, queue workers, and shared storage, we've written up the anatomy of a zero-downtime deploy in detail. Deploynix has used the same releases-plus-symlink model since day one, so consider this one point of genuine convergence: the whole ecosystem now agrees on how Laravel deploys should work.

The Redesign Is Actually Faster

Old Forge accumulated a decade of UI. The new interface loads faster, groups settings sensibly, and the command palette makes jumping between servers and sites quick. This sounds cosmetic, but if you touch your deployment panel daily, interface speed is a real quality-of-life gain. No caveats here.

Laravel VPS Removed a Real Onboarding Step

Before Laravel VPS, the very first thing a new Forge user did was leave Forge: go create a DigitalOcean or Hetzner account, generate an API token, come back, paste it in. For a beginner deploying their first app, that detour was where a meaningful number of people stalled.

Laravel VPS collapses that: sign up, click, and you have a running server in under 10 seconds. For prototypes, client demos, and first deployments, that's a legitimately great experience. Provisioning a fresh server on a cloud provider API typically takes a few minutes; sub-10-seconds suggests Laravel is handing you a pre-warmed instance, and the effect is that "deploy my app" stops feeling like an infrastructure project.

Laravel VPS: The Fine Print Nobody Reads at Launch

Here's where the practitioner's assessment diverges from the launch coverage. Laravel VPS is convenient precisely because of a trade you should make with your eyes open: the server lives on Laravel's infrastructure, under Laravel's pricing, inside Laravel's platform.

You Don't Own the Account Underneath

With bring-your-own-VPS, there are two relationships: you and your cloud provider (Hetzner, DigitalOcean, wherever), and you and your management panel (Forge, Deploynix, whatever). Cancel the panel and your server keeps running untouched. You still have root SSH, the provider's console, snapshots, and backups. The panel is a layer you can peel off.

With Laravel VPS, those two relationships collapse into one. The server exists inside Forge. If you decide to leave, you're not just switching panels; you're migrating hosts. That's a fundamentally stickier arrangement, and stickiness is the point. It's not sinister, it's the same model every PaaS uses, but you should price it in before you build on it.

You Take Their Pricing, Not the Market's

The market for commodity VPS compute is brutally competitive, and the spread is enormous. A 4 GB Hetzner instance runs about €7.99/month, while a comparable 4 GB DigitalOcean droplet is $24/month, three times the price for similar specs. Egress is even more lopsided: overage bandwidth costs roughly €1.19/TB on Hetzner versus $10/TB on DigitalOcean and around $90/TB on AWS.

When you bring your own server, you get to arbitrage that spread. You can put your app on Hetzner, your US-latency-sensitive workload on Vultr, and your compliance-bound client on AWS, and manage them all from one panel. With Laravel VPS, the $6 entry point is attractive, but as you scale up the tiers you're paying whatever Laravel charges, with no ability to shop the underlying compute. For a side project, irrelevant. For a SaaS whose server bill grows with revenue, it compounds. We've broken down what the Hetzner route looks like in practice in our Hetzner price-to-performance guide.

Flexibility at the Edges

Owning the provider account also means owning the escape hatches: resizing to whatever instance type the provider offers (including CPU-optimized or dedicated-vCPU shapes), taking provider-level snapshots before risky changes, attaching block storage, moving a server between projects or teams at the provider level, or handing the whole account to a client at the end of an engagement. Client handoffs in particular are a big deal for agencies: "the server is in your DigitalOcean account, here are the keys" is a clean ending. "The server is inside our Forge organization" is not.

None of this makes Laravel VPS bad. It makes it a PaaS-shaped choice wearing VPS clothing. And it's worth noting the industry backdrop: a Barclays CIO survey found 86% of CIOs plan to move at least some workloads back off public cloud platforms, up from 43% in 2020, and 37signals has documented roughly $2M/year in savings from leaving AWS. The broad movement is toward owning your infrastructure, not renting it through more layers. Laravel VPS swims against that current, deliberately, in exchange for convenience.

Organizations: A Better Model with a Per-Seat Meter Attached

Replacing Circles with Organizations was the right structural move. Circles were always a workaround: a way to share servers that predated any real concept of a team. Organizations bring proper membership and permissions, and if you've managed a multi-developer Forge account, it's a clear upgrade.

The catch is the pricing model that came with it. Organizations meter by people: your cost scales with the number of humans you add. For a solo developer, that's invisible. For a five-person team, every hire now has an infrastructure-panel line item attached, and the incentive it creates is quietly corrosive: teams start sharing logins to avoid seats, which defeats the entire purpose of an audit-trailed permissions model.

This is the single sharpest philosophical difference with Deploynix, which includes team seats on every tier, including the Free plan. The reasoning is simple: a deployment panel gets safer as more of the team can see it, so charging per set of eyeballs optimizes for the wrong thing. Whether that difference matters to you depends entirely on your headcount; solo developers can skip this section's implications, five-person agencies cannot.

Forge 2.0 vs Deploynix, Feature by Feature

Here's the honest side-by-side as of July 2026. Where the products differ in kind rather than degree, the notes below the table explain.

Three rows deserve honest elaboration.

Rollback is a difference of friction, not capability. Both products keep old releases on disk, so both can technically return to a previous version. The distinction is what that costs you at 2 a.m.: on Deploynix, rollback is a single click that swaps the symlink back and restarts your workers. On Forge, you're working with the retained releases yourself. When a deploy goes sideways in front of users, the gap between "click" and "figure it out under pressure" is exactly when it matters most. A rollback path you've never rehearsed isn't really a rollback path, and defaults decide what gets rehearsed.

Monitoring measures different things. Forge's health checks answer "is my site responding, from three places in the world?" That's outside-in uptime monitoring, and it's useful. Deploynix's monitoring answers "is my server about to fall over?" with CPU, memory, and disk telemetry plus alert thresholds. Ideally you want both kinds; neither product fully replaces a dedicated observability tool, and pretending otherwise would be marketing, not analysis.

The providers row is a philosophy, not a checklist. Both products connect to the major clouds and custom servers. The difference is direction of travel: Forge 2.0's flagship addition pulls hosting inward onto Laravel's infrastructure, while Deploynix deliberately has no hosting of its own, so its incentives stay aligned with you shopping for the cheapest, best-fit compute. Neither stance is wrong. They're bets on different futures.

For a wider comparison that includes Ploi, see our three-way honest comparison.

Who Should Stay on Forge

Being fair means saying this plainly: for a lot of people, Forge 2.0 removed the reasons to leave.

Stay if you're a solo developer who's already there. The old arguments for switching (in-place deploys, dated UI) are gone. Zero-downtime is default, the panel is fast, and per-user pricing doesn't bite a team of one. Migration has a cost, and for you the payoff is thin.

Stay if first-party matters to you. Forge is built by the people who build the framework, and the surrounding ecosystem is real: Laravel Cloud now offers managed application hosting from $5/month with scale-to-zero hibernation, and Forge slots into that product family. If you want one vendor accountable for your whole stack, from framework to host, that's a coherent position and Laravel is the only one who can sell it to you.

Stay if Laravel VPS fits your actual workload. Prototypes, demos, course projects, low-stakes client sites: the sub-10-second provisioning and the $6 entry tier are hard to beat for speed-to-running-app, and the lock-in concerns above genuinely don't matter for throwaway infrastructure.

Stay if you're mid-launch or mid-crisis. A deployment platform migration is one of those tasks that's easy in a quiet week and reckless in a busy one. If you're weeks from a launch, onboarding a big client, or firefighting production issues, the switching math doesn't change but the timing does. Bookmark the comparison, ship the thing, and revisit when the calendar clears. Forge 2.0 is a perfectly good place to be standing while you decide.

Who Should Reconsider

Reconsider if you're a team paying per seat. Add up your Organizations bill and compare it against a flat $12 to $39/month with unlimited team members. For agencies and product teams of three or more, this is usually the largest single line-item difference, and it grows with every hire.

Reconsider if your strategy is cheap compute. If your cost model is built on Hetzner's €7.99 4 GB instances and €1.19/TB egress, you want a panel whose incentives point the same direction as yours: toward your own provider account, resized and shopped at will. A management layer that also sells hosting will always, structurally, nudge you toward its hosting.

Reconsider if exit-cost bothers you. If reading the Laravel VPS section made you slightly uncomfortable, trust that instinct. Owning the provider account means any panel, Deploynix included, remains a removable layer rather than a landlord.

If you land in this second group, the switch is more mechanical than you'd expect: server provisioning, site setup, SSL, queues, and cron all map one-to-one. We've documented the whole process, including how to cut over DNS without downtime, in our Forge-to-Deploynix migration guide.

Where This Leaves You

Nine months later, the honest scorecard on Forge 2.0 reads like this. The engineering was real: zero-downtime by default fixed the product's oldest flaw, the redesign made daily use faster, and Laravel VPS built the smoothest first-deploy experience in the ecosystem. Anyone telling you Forge 2.0 was just a coat of paint hasn't used it.

But the strategic direction shipped alongside the engineering. Laravel VPS moves hosting onto Laravel's infrastructure and pricing, and Organizations put a per-person meter on team access. Both are defensible business decisions, and both shift cost and control away from you in ways the launch posts didn't dwell on.

So the Forge-alternative decision in mid-2026 is no longer "Forge is dated, look elsewhere." It's a cleaner question: do you want convenience that deepens your dependence on one vendor, or ownership that keeps every layer of your stack replaceable? If it's the former, Forge 2.0 is the best it has ever been, and you should use it without apology. If it's the latter, that's the exact position Deploynix was built for: your servers, your provider account, flat pricing, and your whole team in the room. The pricing page and the migration guide are there when you've decided which kind of team you are.