The Hidden Costs of Self-Hosting: A Realistic Monthly Bill

Ask anyone who self-hosts what it costs and they'll quote the server price, because that's the number they can point at. It's also the least interesting number in the whole picture. Build the line-item bill from published rates and it comes out small — small enough that the actual story is everything that never shows up on an invoice at all.

The migration math itself is covered in moving a SaaS off Vercel to a €5.50 VPS, and this post deliberately doesn't repeat it. Folding "the bill" and "the real cost" into one post buries the second under the first. This is the counterweight: line items first, from vendor pricing pages, then the parts nothing invoices. For the operations playbook that sits alongside the hidden costs of self-hosting, see XenGrowth.

What's actually on the invoice each month?

Modelling a small SaaS on a single server — one Contabo Cloud VPS 4, plus object storage and email sized for a modest, real workload rather than a hypothetical maximum — the line-item bill is genuinely short.

Add it up and the hosting-specific total lands somewhere around €7-9/month for this modelled workload — the VPS, the backup add-on, and a small storage overage, with email contributing nothing because the modelled volume sits inside Resend's free tier. That's a model built on a stated assumption about workload size, not a claim about what any particular app will actually spend; a busier app pushes past these free tiers faster than it looks.

Are the free tiers actually free, or just free for now?

Free right now, and worth watching rather than assuming permanent. R2's free tier covers 10 GB-month of storage plus 1 million Class A and 10 million Class B operations, with zero egress fee at every usage level — that last part is the actual reason R2 gets picked over S3-compatible alternatives, since egress is where S3-style billing usually turns painful. Resend's free tier is tighter: 3,000 emails a month, but capped at 100 a day, which is a ceiling a single busy signup or password-reset day can hit even in a month that's nowhere near 3,000 total.

None of these ceilings are close for a small, single-tenant SaaS. But "free tier" is doing a lot of quiet work in every self-hosting cost comparison, including the model above — if usage tripled, the invoice would still be small, but it wouldn't still show a $0 on those two lines, and a real plan should say so instead of pretending free tiers are a permanent floor.

So where does the real cost actually go?

Into time, mostly, and time doesn't arrive as a line item you can screenshot, which is exactly why so many "I saved money by self-hosting" posts underreport it. Three buckets cover most of it: the migration itself, ongoing maintenance, and being the answer to "who gets paged." There is a longer treatment of the operations side of this in The XenGrowth resource library.

1. The migration — provisioning, hardening the box, moving the database, testing, cutting over DNS, and watching for errors afterward

2. Ongoing maintenance — patching the OS, updating the deploy layer, rotating backups, occasionally reading logs when something looks slightly off

3. Being the answer to "who gets paged" — which used to be a platform's infrastructure team and is now whoever set the alert thresholds

None of these have a clean dollar figure, and manufacturing one — "my time is worth $X/hour, therefore self-hosting cost me $Y" — would be more precise-looking than honest. What can be said without hedging is the shape of where the time goes: hardening the box before anything else touches it (covered fully in how to secure a fresh VPS), the database migration and its verification window, and the DNS cutover — in that order, and each one reliably takes longer in practice than it looks on paper.

What does owning on-call actually mean, day to day?

It means an uptime monitor pings the app on a schedule, and if it doesn't answer, the alert goes to whoever owns the box instead of into a platform's incident queue that someone else is staffed to watch. Most months, nothing happens. The cost isn't the incidents — it's the standing obligation, the fact that you can't fully check out from infrastructure the way you could when a managed platform owned that surface. That's a real cost even in months where nothing ever fires, and it's the part most self-hosting writeups skip past.

• A managed platform's incident response is invisible by design — that invisibility is itself a feature, and it's easy not to register it until it's gone

• Self-hosting means choosing your own alert thresholds, which means false alarms are your fault and missed alarms are also your fault

• There's no shared on-call rotation for a one-person setup, which is fine at small scale and stops being fine the moment it isn't

• The upside is real: you end up understanding your own failure modes in a way a managed platform's abstraction was specifically built to make unnecessary

Self-hosting doesn't make cost disappear. It moves it from a number you can point to on an invoice to a number you have to notice yourself — hours, attention, the weight of being the one who's on call. Both are real. Only one of them shows up on a bill.

So is it actually cheaper, all in?

On the invoice alone, for the traffic shape this model assumes, yes — by a wide margin against a comparable managed platform's Pro-tier base price alone, before any of its own overage. Counting time honestly narrows that gap, but for most solo operators it doesn't close it, mostly because the time cost is front-loaded into one migration window and thins out fast afterward, leaving patching and monitoring at something closer to minutes a week than hours.

Where the trade stops being obviously good is if your time is worth more, per hour, than the gap between the two bills divided by the hours self-hosting actually takes. For a lot of solo founders that math still favors self-hosting, because the hours are concentrated up front. For a funded team whose payroll already covers someone to own infrastructure, the math flips just as fast the other way — and paying the platform premium is the more rational call there, not a lesser one. XenGrowth on governed AI marketing workflows covers the AI agents and marketing automation side of this.

What's the actual difference against staying on a managed platform?

It's worth stating plainly what the comparison actually is, rather than leaving it implied. A managed platform's Pro-tier seat price alone runs well past the entire modelled bill in this post, before any of that platform's own metered overage even enters the picture. That gap is real and it's the reason this whole cluster of posts exists. But a gap on the invoice isn't the same claim as a gap in total cost, and conflating the two is exactly the mistake this post is trying to correct for.

The honest version: the invoice gap is large and immediate. The time-cost gap is smaller than it looks and mostly front-loaded into the migration itself. Whether the two together add up to a genuinely better deal depends on how much you value the hours, and on whether the traffic shape is the steady, predictable kind this whole model assumes in the first place — spiky, unpredictable traffic changes the math in the platform's favor regardless of the invoice.

What's the cost of things going wrong, not just things going right?

Every number above assumes a boring month — nothing crashes, nothing needs restoring, no security patch is urgent enough to interrupt anything else. That's a real assumption, and it's worth naming instead of leaving implicit, because the modelled bill looks very different across a year that includes one bad week than across twelve boring ones.

• A failed restore test costs nothing but the hour it takes to run — a failed restore during a real incident costs the entire outage window on top of the data loss it was supposed to prevent

• A missed security patch usually costs nothing at all — until it's the one that mattered, at which point the cost is whatever the resulting incident actually costs, not a subscription line item

• A misconfigured alert threshold costs a little sleep from false positives, or a missed real incident from being tuned too loose — both are real costs with no dollar figure attached

• None of these are priced into the modelled bill above, because they're contingent, not recurring — but contingent isn't the same as zero, and a fair account of self-hosting's real cost has to say so

What do you actually own now that you didn't before?

Ownership is the honest word, and it cuts both ways. You own the OS patch schedule now, which means a kernel CVE is your problem to notice, not a background item on a platform's infrastructure team's board. You own the backup restore process — which is worth testing deliberately, once, specifically so the first real test isn't during an actual emergency. You own the decision of when to upgrade the box, because nothing upgrades it for you the way autoscaling silently would have. None of these are individually hard. Collectively, they're a checklist that used to not exist for you at all. On AI search, GEO and discovery specifically, XenGrowth on building one SEO and GEO content system is worth reading.

• OS and security patching — scheduled, not automatic, which means it only happens if it's on the calendar

• Backup verification — a backup nobody has restored from is a theory, not a backup

• Capacity planning — deciding when 4 vCPU and 8 GB stops being enough is now a judgment call, not a slider a platform moves for you

• Dependency and base-image updates for the deploy layer, the reverse proxy, and every container image the app builds from

What's actually worth deciding before the migration weekend, not during it?

Don't self-host to save money if saving money is the only reason. It works, on the modelled numbers above, but it's a slow, unglamorous kind of working — a few dollars a month, quietly, adding up over a year. The reason it's worth it for the operators who stick with it usually isn't the number. It's understanding, container by container, exactly what the app depends on to stay up — a kind of knowledge a managed platform is specifically designed to make unnecessary. If that tradeoff doesn't interest you on its own terms, the invoice savings alone probably aren't enough to justify the weekend it costs to get there.

Write down, before you start, which costs you're willing to own and which you're not. That decision framework is laid out properly in my rule for deciding what to self-host, and it's worth doing that exercise before the migration, not during it — during it, the pressure to get the app back online makes you say yes to owning everything. Decide in advance which pieces you'd rather keep paying someone else for, regardless of price. Email is a common one people never seriously consider self-hosting. Your list will look different, and that's fine, as long as you actually write it down instead of discovering it under duress at 2am.

The invoice was never the whole story — it's just the part that fits neatly into a screenshot. If you're weighing this trade for your own product and want a second opinion on where the real costs would land, that's exactly the kind of audit I take on through services.

Further reading from XenGrowth

• The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.

• XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.

• XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.

Where this work meets go-to-market

If the hidden costs of self-hosting is part of a growth programme rather than a standalone build, XenGrowth's operator guides is the companion reading.