In June 2026, Laravel Cloud restructured its pricing around three tiers: a $5/month Starter, a $20/month Growth, and a $200/month Business plan. The headline feature is scale-to-zero hibernation: idle apps go to sleep, wake in under 500ms, and you can set spending caps so a traffic spike never turns into a four-figure invoice.
On paper, that reads like the end of the $5 VPS. Why manage a Linux box when a first-party platform runs your app for the same monthly price?
Because "$5/month" means two very different things on a usage-metered platform and on a flat-rate server. One is a floor. The other is the bill. This post does the total-cost-of-ownership math for a real Laravel app, the kind with a web process, a queue worker, a scheduler, a MySQL database, and a Valkey cache, and shows where each option genuinely wins. Laravel Cloud is a good product. It's also not the cheapest way to run every Laravel app, and the difference is bigger than most comparisons admit.
What $5 Actually Buys on Laravel Cloud
The $5 Starter tier is an entry point into a usage-metered platform, not a fixed allocation of hardware. You pay the base fee, and then compute, database, and data transfer are billed by what you consume. The June update added the two features that make the low tier viable: hibernation, so an idle app consumes nothing, and spending limits, so consumption has a ceiling you choose.
For the right app, this is a genuinely great deal. A portfolio site, a demo you show clients twice a month, a side project with three users: these apps are idle almost all the time, and on a flat-rate VPS you're paying for that idle time. Scale-to-zero means you mostly pay the $5 base and very little else. The sub-500ms wake is fast enough that visitors won't notice the app was asleep.
But "a real Laravel app" is rarely just a web process. Here's where the model starts to strain.
Queue workers don't hibernate well
Hibernation saves money when nothing is running. A queue worker's entire job is to run continuously. If you use Laravel Horizon, there's a master process supervising worker processes that poll Redis constantly, that's how Horizon works by design. A process that polls every second can never scale to zero, so that compute is metered around the clock. You've reintroduced the always-on cost you thought hibernation eliminated, except now it's usage-billed instead of flat.
The alternative is letting the queue sleep and accepting that jobs wait until something wakes the app. For a contact-form email, fine. For a SaaS where a user expects their export or their webhook processed within seconds, not fine.
The scheduler is a wake-up call, literally
Laravel's scheduler assumes a cron tick every minute. Every tick is a wake event for a hibernated app. An app that "sleeps when idle" but runs schedule:run every 60 seconds is never meaningfully idle. You can space out your scheduled tasks, but most production apps accumulate them: queue pruning, backup triggers, subscription checks, cache warming. The scheduler quietly converts a scale-to-zero app back into an always-on one.
The database never sleeps at all
Your database instance and your cache store are separate metered line items, and unlike the web tier, your data can't hibernate away. Whatever the per-hour or per-GB rate, it accrues 24/7. On the $5 tier, the database is routinely the largest number on the invoice, and it's the one the marketing page talks about least.
None of this is a criticism of the engineering. It's the inherent shape of usage-metered platforms: the pricing is brilliant for idle workloads and mediocre for steady ones. The question is which one your app is.
What $5 to $9 Buys on a VPS
A Hetzner CX22 costs about $5/month and gives you 2 vCPUs, 4 GB of RAM, and 40 GB of NVMe storage. Not credits, not compute units: a whole virtual machine that's yours around the clock. Stepping up, Hetzner's CPX-class 4 GB instance runs about €7.99/month, where DigitalOcean charges $24/month for a comparable 4 GB droplet, so even among VPS providers the spread is wide.
On that one box you run everything the small SaaS needs:
- Nginx and PHP-FPM serving the app
- Horizon supervising your queue workers, 24/7, at no marginal cost
- The scheduler ticking every minute, at no marginal cost
- MySQL with several gigabytes of RAM for its buffer pool
- Valkey for cache and queues
That last point is the structural difference. On a flat-rate server, an always-on queue worker costs you nothing extra. The CPU cycles are already paid for. The very workloads that break the scale-to-zero pricing model, workers, schedulers, databases, are exactly the workloads a VPS absorbs for free.
And 4 GB of RAM goes further than people assume. We've load-tested Laravel on a $5 server and a tuned single box comfortably handles the traffic of most small SaaS products, tens of thousands of requests a day, without breathing hard.
Egress is the sleeper line item. Hetzner charges roughly €1.19/TB for overage beyond its generous included transfer, DigitalOcean around $10/TB, and AWS-style platforms roughly $90/TB. If your app serves file downloads, images, or API responses at any volume, metered egress on a hyperscaler-backed PaaS can quietly exceed your entire VPS bill.
The Hidden Line Items, in Both Directions
An honest comparison has to count the costs each side's fans prefer to skip.
What PaaS invoices actually accumulate
- Database and cache. Metered separately, billed continuously, and sized by usage you can't always predict. This is usually the gap between the $5 headline and the real monthly total.
- Always-on compute. Queue workers and frequent schedulers, as covered above.
- Egress. Metered per GB, at hyperscaler-adjacent rates rather than Hetzner rates.
- Extra environments. A staging environment is a second app with its own compute and its own database. On a VPS, staging is a second site on the same box, and it costs nothing.
- The cap trade-off. Spending limits are a real improvement, and credit where due, Laravel shipped them. But a cap protects your bill, not your workload: the ceiling you set is the point where you've chosen cost over capacity. A flat-rate server never presents that choice mid-month.
What the VPS actually costs you
Fair is fair, so here's the other side of the ledger.
- Your time. Someone has to provision the box, configure Nginx and PHP-FPM, set up deployments, and keep it all running. Done by hand, the initial setup is an afternoon and the ongoing care is a couple of hours a month. Your hourly rate makes that real money.
- Security patching. An unpatched VPS is your liability, not a vendor's, and the secrets living on it raise the stakes. The May 2026 Laravel-Lang supply-chain attack pushed 700+ compromised package versions delivering a credential stealer that hunted cloud keys, CI/CD tokens, and SSH keys. A Composer attack like that hits PaaS apps just as hard; the difference is that a self-managed box concentrates more for a stealer to grab,
.envfiles, deploy keys, and server SSH keys included. The baseline is well understood, but it still has to be done. - Backups and monitoring. A PaaS bundles these. On a raw VPS you set up both or you gamble.
- No built-in autoscaling. If your traffic 20x's overnight, a single VPS falls over. For most small apps this risk is theoretical; for a few it's the whole reason PaaS exists.
The honest summary: PaaS converts your time into a metered bill, and a VPS converts a metered bill into your time. A management platform (Forge, Ploi, Deploynix) is the middle path, buying back most of the time for a flat fee. Forge's 2.0 relaunch even added Laravel VPS instances from $6/month with sub-10-second provisioning, which tells you Laravel itself sees the flat-rate server as very much alive.
Three Scenarios, Worked Through
Abstract pricing arguments are useless, so here are three real shapes of Laravel app and where the math lands for each.
Scenario 1: A hobby project with spiky traffic
A side project that gets featured on a newsletter once a quarter and is otherwise near-dead. Traffic: bursts of a few thousand visits, then weeks of silence. No queue urgency, a couple of scheduled tasks a day, a tiny database.
Laravel Cloud wins, and it isn't close. This is the exact workload scale-to-zero was built for. The app hibernates through the quiet weeks, wakes in under 500ms when the newsletter hits, and the spending cap means a viral moment can't hurt you. A VPS would work fine too, but you'd be paying for a server that idles almost all the time and patching it for an app three people use. Take the $5 tier and move on with your life.
Scenario 2: A steady-traffic SaaS with queues
A small B2B SaaS: a few hundred daily active users, Horizon processing jobs all day (emails, report generation, third-party syncs), a scheduler with a dozen tasks, a 2 GB MySQL database, Valkey for cache and sessions. Traffic is boringly consistent, weekdays 8 to 6.
The VPS wins on cost, clearly. This app is never idle, so hibernation saves nothing. The worker meters 24/7, the database meters 24/7, the scheduler wakes everything every minute anyway. Every attribute that makes usage-based pricing attractive is absent, and every attribute that makes it expensive is present. Meanwhile a single $5 to $10 Hetzner box runs the entire stack at a fixed price, with the always-on worker and database costing literally nothing extra. This is the workload where flat-rate infrastructure is at its strongest, and it happens to describe most bootstrapped SaaS products.
There's a reason the broader industry is rediscovering this. A Barclays CIO survey found 86% of CIOs plan to move some workloads back from public cloud, up from 43% in 2020, and 37signals reports saving around $2M per year, roughly $10M over five years, after leaving AWS. Steady workloads on metered infrastructure is the pattern everyone eventually notices on the invoice.
Scenario 3: An agency with many client apps
Fifteen client sites: marketing sites, a few small apps, two or three with queues. Each client billed monthly for hosting and maintenance.
VPS plus a management platform wins, structurally. On a per-app-priced PaaS, fifteen apps means fifteen base fees plus fifteen sets of metered databases before you've written a line of code, and the invoice scales linearly with every client you sign. On flat-rate servers, several small client sites share one box, bigger clients get their own, and your management platform gives every project the same deploy pipeline, SSL automation, and monitoring. Your hosting margin improves with every client instead of staying flat. This is also where team seats matter: agencies have juniors, contractors, and project managers who all need dashboard access, and per-seat pricing punishes exactly that.
The 12-Month Table: A Typical Small SaaS
Here's Scenario 2 priced over a year. The VPS column uses published flat rates. The Laravel Cloud column is honest about what's knowable: the base fee is fixed and public, while compute, database, and transfer are usage-metered and vary by app, so we mark them as such rather than inventing numbers.
Line item
Laravel Cloud
Hetzner VPS + Deploynix
Base plan
$5–20/mo ($60–240/yr)
$0
Server
included (web tier)
Hetzner CX22, ~$5/mo ($60/yr)
Queue worker (24/7)
metered, cannot hibernate
included on the same box
Scheduler
metered wake events
included (cron)
MySQL/Postgres
metered, billed continuously
included on the same box
Valkey/Redis cache
metered
included on the same box
Staging environment
second app + second database, metered
second site on same box, $0
Egress
metered per GB
~€1.19/TB overage, generous included quota
Management platform
n/a (built in)
Deploynix Starter, $12/mo ($144/yr)
Backups
included
pennies per month to S3-compatible storage
SSL, deploys, monitoring
included
included in Deploynix
12-month total
$60–240 floor + metered usage
~$205 flat, all-in
Read that last row carefully. The VPS column is a ceiling: roughly $205 for the year, known in advance, regardless of how busy your queue gets. The Cloud column is a floor: $60 to $240 before any metered usage, and for an always-on app with a database, the metered usage is the bulk of the bill. If you'd rather skip the platform fee entirely and manage the box by hand, the year costs ~$61 plus your time, and only you know what your time is worth.
For a hibernating hobby app, the same table inverts: the Cloud column collapses toward its $60 floor and the VPS column becomes money spent on idle silicon. The table doesn't have a winner. Your traffic pattern picks one.
Where Deploynix Fits
Deploynix exists for the middle path in that table: you own flat-rate servers, and a flat-rate platform removes the sysadmin work that makes people flee to PaaS in the first place.
The Starter plan is $12/month, flat, with no usage metering of any kind. It provisions servers on Hetzner, DigitalOcean, Vultr, Linode, AWS, or any VPS you can SSH into, then handles the parts you'd otherwise do by hand: zero-downtime deployments with one-click rollback, free Let's Encrypt SSL, MySQL provisioning with automated backups, cron, and queue workers and Horizon under Supervisor. Team seats are included on every tier, including Free, so the agency in Scenario 3 doesn't pay per collaborator. The Hetzner-plus-Deploynix combination is the specific pairing we'd recommend for Scenario 2: the cheapest solid hardware in the industry under a fixed management fee.
That's the extent of the pitch. The point of this post is the math, and the math doesn't always favor us either: for Scenario 1, we'd genuinely tell you to use Laravel Cloud.
A Decision Framework
Skip the brand loyalty and answer four questions about your actual app:
Is your app idle more than half the time? If yes, scale-to-zero is real money saved and Laravel Cloud's $5 tier is probably your cheapest option. If your app serves steady traffic, hibernation saves you nothing and you're paying metered rates for always-on work.
Do queues need to process within seconds, around the clock? An always-on Horizon worker is free marginal capacity on a VPS and a continuous metered charge on a PaaS. Latency-tolerant queues weaken this; busy real-time queues make it decisive.
How big is the database, and does it grow? Your data can't hibernate. A continuously metered database is the line item that most often drags a "$5" PaaS bill into serious territory, while on a VPS it's RAM you already own.
How many apps are you running? One app: either model works. Ten apps: per-app base fees and per-app databases stack up fast, and shared flat-rate servers win on structure, not just price.
Rough scoring: mostly-idle single app, take Laravel Cloud and enjoy it. Steady SaaS with queues, take a VPS. Many apps or client work, take VPSes plus a management platform and protect your margins.
The Bottom Line
Laravel Cloud's $5 tier is a real product improvement, not a gimmick. Scale-to-zero with sub-500ms wakes and spending caps solves the exact problem that made usage-based platforms scary for hobbyists, and for spiky, mostly-idle apps it's the best deal in the Laravel ecosystem right now.
But the $5 is a floor, and floors are only meaningful for apps that stay near them. The moment your Laravel app looks like production, an always-on worker, a scheduler, a growing database, a cache, the metered model charges you for every hour of that steadiness, while a $5 Hetzner box absorbs all of it at a fixed price. Over 12 months, a typical small SaaS runs about $205 flat on a VPS with Deploynix managing it, versus a $60 to $240 floor plus open-ended usage on the platform side.
Price the app you actually have, not the demo. If it sleeps, rent the nap. If it works for a living, buy it a server.
Top comments (0)