Laravel Cloud vs Forge + Hetzner vs a bare VPS: 60 days of real bills

On 15 June 2026 we deployed the same production Laravel application three times: once to Laravel Cloud, once to a Hetzner VPS managed through Laravel Forge, and once to an identical Hetzner VPS we provisioned entirely by hand. For the next 60 days all three ran the same replayed traffic while we logged every invoice line and every ops hour. Nobody, as far as we can find, has published real usage-based Laravel Cloud invoices next to the alternatives. Before the aggregate, the anatomy: day 1 and day 60 of the same app's three invoices.

Anatomy, day 1: one app, three deployments, three meters started

The app is an anonymised client platform consistent with the rest of our Laravel portfolio: a B2B operations platform for an energy-sector business, where tendering workflows and billing reconciliation are the domain core. Laravel 12 API, Vue 3 front end (Vue + Laravel is our most-shipped pairing), MySQL 8 with a 6.2GB working database, Redis for cache and queues, Horizon supervising two workers, and a scheduler carrying 14 entries, including a nightly reconciliation job and a monthly document sync to Cloudflare R2. Traffic is the classic B2B shape: roughly 400K requests a month, concentrated into UK weekday business hours, near silent from 22:00 to 06:00 and most weekends, p95 request rate under 9 requests per second.

"The same app" is doing a lot of work in that sentence, so here is what parity actually meant. All three legs ran the same commit at all times, the same PHP 8.4 with identical opcache settings, the same environment variables apart from connection strings, the same two Horizon workers with the same queue weights, and the same 14 scheduler entries firing on the same UTC schedule. Sessions and cache went to Redis on every leg so no platform got an architectural handicap. Where a platform made a choice for us (Laravel Cloud picks its own PHP runtime and process supervisor, Forge templates its own nginx config) we accepted the default, because the study is about what each path costs when you use it the way its vendor intends, not about how far you can bend each one toward the others.

Leg one, Laravel Cloud.We connected the repository, picked a region, and had the app serving production traffic 41 minutes after first login, DNS included. Two environments: production and a staging environment allowed to hibernate. The one real porting job: Laravel Cloud's managed database is Serverless Postgres, so this leg ran Postgres while the other two ran MySQL. Migrations were driver-clean but a handful of raw MySQL expressions in report queries cost us 2.5 setup hours. Day 1 spend: $0. The meter simply started.

Leg two, Forge + Hetzner.A CX32 instance (4 shared vCPUs, 8GB RAM, 80GB disk) provisioned through Forge: nginx, PHP 8.4, MySQL 8, Redis and the scheduler configured for us, Horizon set up as a Forge daemon, Let's Encrypt issued, push-to-deploy wired. One hour 55 minutes from console to production. Day 1 committed spend: $12 for the Forge plan, €8.16 for the server including backups, about $21.55/mo all in.

Leg three, the bare VPS.The same CX32, provisioned by hand: SSH keys only, ufw, fail2ban, unattended-upgrades, nginx and PHP-FPM tuned manually, MySQL and Redis installed and configured, systemd units for Horizon, certbot for TLS, and our own atomic-release deploy script (reproduced below). That first day cost 6.2 hours of a senior engineer's time. The invoice: €8.16/mo, about $9.55. The real cost was the day.

Anatomy, day 60: the same three invoices again

Sixty days later the three bills told a story none of the pricing pages tell. Laravel Cloud's month one invoice came to $86.41: $20 platform fee, $34.20 of metered compute across the web environment and two workers, $19.72 of Serverless Postgres, $12.49 of bandwidth and storage. Month two, after we right-sized the compute allocation and tightened staging hibernation, came to $66.87, a 23% drop for roughly the same traffic. Forge + Hetzner billed $21.55 both months, to the penny, which is the entire appeal. The bare VPS billed $9.55 both months and quietly consumed 3.4 hours a month of patching, certificate babysitting and memory-leak triage.

The texture behind those totals matters as much as the totals. The Laravel Cloud invoice is eleven lines of metered detail: compute hours by environment, database compute and storage separately, egress by the gigabyte. The Forge and Hetzner invoices are one line each, and the bare VPS ops log is where its detail hides instead: a kernel update and reboot window at day 18, the silent certbot failure at day 47, a log-rotation config after the first disk alert, a Horizon restart policy after a slow memory leak. None of it appears on any invoice, which is precisely why VPS hosting looks so cheap from the outside.

Ranked by invoice: VPS, then Forge, then Cloud. Ranked by what the month actually cost once the hours are priced: exactly the reverse. That inversion is the whole study, and the rest of this post is the evidence for it, in the same stopwatch-and-invoice format as our PaaS deploy comparison.

Methodology

One production Laravel application, three parallel deployments, 15 June to 13 August 2026, split into two 30 day billing windows. Traffic was replayed from the platform's real access logs at original pacing (412K requests in window one, 396K in window two), so all three legs saw identical request shapes, identical queue load and identical cron schedules. We measured four things: the monthly bill as invoiced, ops hours logged per leg in our time tracker, deploy and rollback mechanics timed across 23 releases shipped to all three legs, and scale-to-zero behaviour on the Cloud leg (compute-hours billed against the always-on equivalent). Engineering time is priced at our blended $75/h rate. Setup hours are reported separately from steady-state ops hours so a one-off day does not pollute the monthly figure.

Two things we deliberately did not measure. First, raw performance: all three legs served the replayed traffic with p95 response times within 8% of each other, which is what you would expect when the same Laravel app runs on broadly similar compute, so there is no performance chart because there is no performance story. Second, feature work: engineering hours spent on the application itself are excluded from OHM entirely, because they are identical across legs by construction. OHM counts only the hours a hosting path imposes: patching, certificates, deploy machinery, incident response, and dashboard tuning.

The client whose platform and traffic we replayed consented to anonymised publication of the bills, timings and ops logs, and reviewed the anonymisation before this post went live.

What changed in the Laravel hosting market

The reason this comparison needed running at all is that the menu changed. In February 2025 Laravel launched Laravel Cloud alongside Laravel 12: a first-party, usage-based PaaS with metered compute, Serverless Postgres and scale-to-zero, the successor in spirit to Vapor's serverless experiment but without the AWS Lambda shape. Forge meanwhile stayed resolutely flat-rate at $12 to $39 a month for the control plane, with the server itself brought by you, and Hetzner will sell you a perfectly good VPS from about $6 a month. The ecosystem these options serve is not shrinking: Laravel leads the JetBrains State of PHP data at 64% framework share, and in our own stack demand report Laravel sits in the small group of stacks where client demand and developer preference actually agree.

A word on Vapor, because clients still ask. Vapor was Laravel's 2019 answer to serverless: your app repackaged for AWS Lambda, with the cold-start mitigation and database-connection gymnastics that entails. It solved a real problem for a particular era, and some production apps still run happily on it. But the direction of first-party investment since February 2025 is unambiguous, and the practical difference shows in the developer experience: Laravel Cloud behaves like a hosting platform that happens to bill by usage, where Vapor always behaved like AWS wearing a Laravel costume. Every recommendation in this post treats Cloud, not Vapor, as the managed-platform option for new work.

So a Laravel team in 2026 faces three genuinely different postures: rent the whole platform (Cloud), rent the control plane and own the server (Forge + VPS), or own everything (bare VPS). The pricing pages make the choice look like a $10 to $80 question. The bills below say it is really a question about whose hours are on the line.

Finding 1: the bills, side by side

Laravel Cloud's month one bill breaks down as $20 platform fee, $34.20 metered compute, $19.72 Serverless Postgres, $12.49 bandwidth and storage. The 23% month-two drop needed about forty minutes of attention: we lowered the production memory allocation one notch after watching two weeks of headroom, and stopped a QA browser tab from keeping staging awake overnight. That is the double edge of usage-based pricing: it rewards attention and punishes inattention, in both directions. The two Hetzner legs are identical hardware at identical prices; the $12 difference between them is purely the Forge control plane, which turns out to be the cheapest line item in the entire study relative to what it displaces.

Why the CX32, for anyone reproducing this: 4 shared vCPUs and 8GB of RAM is comfortably above what a 400K request month needs, but it is the smallest Hetzner tier we would put a production MySQL and Redis on the same box as PHP-FPM, and the €1.36 backup add-on (20% of the instance price) buys nightly snapshots we actually tested restoring in week one. Hetzner includes 20TB of traffic, so bandwidth never appeared on either Hetzner invoice; the same two months of traffic showed up as real, if small, egress lines on the Laravel Cloud bill. That asymmetry, flat allowances versus metered everything, is a recurring theme once you read the invoices closely.

Finding 2: the hours behind the bills

The bare VPS's 3.4 monthly hours were not exotic: kernel updates and a reboot window, one certbot renewal that failed silently in an nginx reload race and got caught by monitoring, log rotation that needed configuring after the first disk-space alert, and a Horizon worker that needed a memory-limit restart policy. Any competent engineer clears each item quickly. The point is that somebody has to be that engineer, every month, forever. The Forge leg's 2.05 hours were mostly one incident: the nightly reconciliation job OOM-killed MySQL in week five, and adding 2GB of swap plus a tighter chunk size took an evening. Laravel Cloud's half hour a month was reading dashboards and adjusting allocations, which is a different kind of work entirely: cost tuning, not system administration.

At our blended $75/h rate the inversion is complete: the platform with the largest invoice produced the cheapest month, by a factor of 2.3 against the bare VPS. If your rate is lower, or the hours are absorbed by someone already on payroll, the maths moves back toward the Hetzner legs, and we give that scenario its due in the recommendations.

One caution on Cloud's flattering 0.5 hours: usage-based platforms replace system administration with what we started calling the attention tax. Nobody has to patch anything, but somebody should be reading the metering dashboard monthly, because the same mechanism that dropped our bill 23% would happily have run the other direction. An unnoticed retry loop, a chatty health check, a staging environment pinned awake by a forgotten browser tab: on a flat-rate server these cost nothing; on a meter they compound quietly until the invoice arrives. The half hour is real, but it is a recurring appointment, not an absence of work.

Finding 3: deploy and rollback mechanics

We shipped 23 releases during the window, every one pushed to all three legs, timed from push to serving. The methodology matches our zero-downtime PaaS study: what matters in production is not the average deploy but the worst rollback.

The nuance the table hides: Forge's stock deploy runs in place, a git pull in the live directory, which leaves a window of a few seconds while composer swaps the vendor directory. At our traffic we never caught a user-visible error in 23 deploys, but we would not run a high-stakes sales window through it without adding an atomic-release recipe or Envoyer. The bare VPS wins both stopwatch columns because we built exactly the machinery we wanted, and that six second rollback is the reward. The script is short enough to publish in full:

#!/usr/bin/env bash
# deploy.sh :: atomic-release deploy for the bare VPS leg
set -euo pipefail

APP_ROOT="/srv/app"
RELEASE="$APP_ROOT/releases/$(date +%Y%m%d%H%M%S)"

git clone --depth 1 git@github.com:acme/platform.git "$RELEASE"
cd "$RELEASE"

composer install --no-dev --optimize-autoloader --no-interaction
npm ci --silent && npm run build

ln -s  "$APP_ROOT/shared/.env"    "$RELEASE/.env"
rm -rf "$RELEASE/storage"
ln -s  "$APP_ROOT/shared/storage" "$RELEASE/storage"

php artisan migrate --force
php artisan config:cache && php artisan route:cache && php artisan view:cache

# the atomic bit: one symlink flip, rollback is the same flip backwards
ln -sfn "$RELEASE" "$APP_ROOT/current"
sudo systemctl reload php8.4-fpm
php artisan queue:restart

# keep the last five releases for instant rollback
ls -dt "$APP_ROOT"/releases/* | tail -n +6 | xargs -r rm -rf

Every line of that script is a thing Forge or Cloud would otherwise own: dependency install, shared storage symlinks, config caching, FPM reload, queue restart, release pruning. It took an afternoon to write and harden, it never failed in 60 days, and it is also precisely the artefact you are signing up to maintain for the life of the app when you choose the bare path.

Two mechanics deserve a closer look than the stopwatch gives them. Database migrations ran inside the deploy on all three legs, and 4 of our 23 releases carried one; every platform handled the forward path cleanly, but only the rollback stories differ. Cloud's previous-build rollback and our symlink flip both restore old code against a new schema, so a destructive migration makes the fast rollback a lie on any platform: expand-and-contract migration discipline is what actually makes those 6 and 20 second numbers honest. And queue restarts are the silent deploy step people forget: all three legs call php artisan queue:restart or its platform equivalent, but a worker mid-job holds the old code until the job finishes, which is why our long-running reconciliation job pins its own release assumptions rather than trusting the deployment boundary.

Finding 4: what scale-to-zero actually saved

Here is the finding we most wanted a real number for. Our app has the perfect traffic shape for scale-to-zero: silent nights, silent weekends. And production still only saved 31% blended across the two windows, because a production app is never actually idle. The uptime monitor pings every 60 seconds. Horizon workers hold their allocation waiting for jobs. The 02:00 reconciliation cron woke the environment for 22 minutes every night. Scale-to-zero is real, but on a production environment it behaves like scale-to-floor.

Staging is the honest success story: 88% SZS, because a staging environment genuinely is idle between QA sessions. The cost of that saving is the wake-up: cold starts after full hibernation measured 3.1s at the median and 6.8s at p95. Fine for a QA engineer opening a preview link; not something you want a customer to hit. If your production traffic ever truly stops, a paused project for instance, the bill falls toward the $20 platform fee, and we found that genuinely useful, as the Rail.One story below shows.

Could we have engineered production's 31% higher? Somewhat. Batching the overnight scheduler entries into one window instead of letting them fire across four hours would have cut the wake-ups; moving the uptime check to a five minute interval would have let compute idle deeper between pings; and a queue-on-demand pattern, where workers only claim compute when jobs exist, is the design Cloud's model quietly rewards. We chose not to, because the study's job was to measure the platform against a normal production configuration, not against an app rebuilt to flatter the meter. But if you are designing a new app for Laravel Cloud from day one, the lesson is real: scale-to-zero is partly an architecture you write, not just a feature you receive.

How we measure hosting cost

1. Effective Monthly Bill (EMB)

EMB = Average invoice + (OHM x blended hourly rate)

The number the pricing pages refuse to print. Across our three legs at $75/h: Laravel Cloud $114.14, Forge + Hetzner $175.30, bare VPS $264.55. Recompute it with your own rate; the ranking is rate-sensitive and that sensitivity is the decision.

2. Scale-to-Zero Savings (SZS)

SZS = 1 - (Metered compute billed / Always-on equivalent cost)

How much of the always-on cost usage-based billing actually returned. Production: 31% blended. Staging: 88%. The gap between those two numbers is the gap between marketing and production.

3. Ops Hours per Month (OHM)

OHM = Hours on patching + deploys + certificates + incident response, per calendar month

Steady-state only; setup is counted once and reported separately. Cloud 0.5, Forge + Hetzner 2.05, bare VPS 3.4. OHM is the metric that decides the study, because it is the one that compounds for the life of the app.

What four production Laravel platforms taught us about this choice

The 60 day benchmark is one app. The reason we trust its shape is that it matches a decade of bills across the four production Laravel platforms we run, each of which stresses a different corner of the decision. A hosting benchmark tells you what a platform costs under controlled conditions; a portfolio tells you which conditions actually occur. Between them, the four platforms below cover the cases the benchmark could not: traffic that spikes vertically instead of ebbing politely, bills too small to optimise, cron jobs that must outlive the platform they run on, and projects that stop dead for months and then restart.

1. Ontick: spikes favour flat rate. Ontick has booked 230K+ tickets and put £2M+ in platform sales through a Laravel + Vue + MySQL stack. Ticketing traffic is the anti-B2B shape: near-vertical spikes the minute a tour goes on sale. A Forge-managed server sized for the spike costs the same on the quiet days, which sounds wasteful until you price what usage-based metering does during the loud ones. For spiky transactional platforms we still size for the peak and pay the flat rate.
2. PES: the perfect scale-to-zero shape that does not need it.The PES tendering ERP has $1M+ in tenders flowing through it and has saved 800+ broker hours. Its traffic is business-hours only, the exact profile Laravel Cloud's metering flatters. It also runs contentedly on one modest Forge box at a bill so small the SZS conversation is not worth the migration. Usage-based pricing needs a bill big enough to be worth shrinking.
3. All White Laser: portability is an ops feature. The AWL contracts portal ($5M in contracts, 500 contract docs) runs a monthly document sync to Cloudflare R2 via standalone PHP migration scripts that deliberately load neither WordPress nor Laravel, so plugin Guzzle conflicts cannot break the cron. Those scripts ran unchanged on all three legs of this study, which is the quiet argument for keeping edge and storage concerns decoupled from the host platform; it is the same pattern behind our Cloudflare edge engineering work and our SDK-free R2 media study.
4. Rail.One: pauses are a billing event. Rail.One is a DE/EN bilingual corporate platform with a Next.js front end on Sanity, and it survived two full project pauses. A paused project on a flat-rate server keeps billing; on usage-based infrastructure it falls toward the platform fee. If your project portfolio includes builds that stop and restart, scale-to-zero is worth more to you than any throughput argument.

Recommendations

If nobody owns ops: Laravel Cloud

For a founder-led team with no in-house DevOps, or a build where every hour is billed at agency rates, Laravel Cloud produced the lowest EMB in this study and the least dangerous failure modes. Budget $70 to $90 a month at around 400K requests, expect to claw back 20% or so with one right-sizing pass, and accept the Postgres default unless your app has deep MySQL assumptions. Watch the meter monthly; usage pricing rewards exactly that attention.

If routine ops live in-house: Forge + Hetzner

This is our default and where most of our Laravel engagements ship: $21.55 a month flat, 49 second deploys, and a control plane that turns server administration into a checklist. Add an atomic-release recipe before any high-stakes traffic window. The EMB penalty in our table assumes agency-priced hours; with an engineer already on payroll doing 2 hours a month of routine Forge maintenance, this leg wins the maths comfortably.

The scaling path is also more graceful than the VPS label suggests. When this app outgrows a CX32, the next move is a resize to the next Hetzner tier, ten minutes of downtime scheduled into a quiet window; after that, splitting MySQL onto its own box and putting two app servers behind a load balancer, all of it still inside Forge's remit. We have run that exact progression on production platforms without ever leaving the flat-rate world, and the bill at the end of it is still less than many teams' first month of metered compute.

If the hours are genuinely free: the bare VPS

The bare VPS is the right answer when compliance demands full control, when the box hosts several apps and amortises its hours, or when the person patching it would be patching servers anyway. It gave us the fastest deploys and the fastest rollbacks in the study. Just price the 3.4 hours a month honestly, because the invoice never will.

Limitations

This is one app with one traffic shape over two billing cycles; a spiky consumer workload would move every number, especially SZS. The Laravel Cloud leg ran Serverless Postgres while the others ran MySQL, so the database columns are close cousins rather than twins. Sixty days overweights early-life ops: the Forge and VPS legs' OHM would trend down as the servers settle, and Cloud's right-sizing gain was a one-off. Currency conversion adds noise to the Hetzner figures, and our $75/h blended rate reflects UK / India agency economics; recompute EMB with yours before deciding anything. Usage-based pricing also changes faster than flat rates, so treat the Cloud figures as a June to August 2026 snapshot, not a durable quote.

The invoice is not the bill

Sixty days, three deployments of the same app, and one conclusion that survives every caveat above: the hosting invoice is the smallest and least honest number in the decision. The real bill is the invoice plus the hours, and once you write both down the three paths stop being competitors and become three different answers to the question of who does the ops. Rent the platform, rent the control plane, or own the machine: the app itself, Laravel with a Vue front end and a queue doing the heavy lifting, ran identically well on all three.

The companion reads: how the deploy mechanics compare across the general-purpose PaaS field, and why clients keep paying for this stack in the first place:

And the engagements this study feeds: the Laravel work itself, and the edge and frontend practices it pairs with: