Self-hosting vs managed cloud: an honest cost and effort comparison

The self-hosting argument usually starts with a screenshot: a Hetzner box with more cores and memory than your cloud bill buys, at a fraction of the price. The managed-cloud argument usually starts with a different screenshot: an incident timeline where a hosted service absorbed a problem your team never had to wake up for. Both screenshots are true. Neither settles the question, because they are measuring different costs.

The honest version of this comparison is not “which is cheaper” but “which is cheaper for you, once you count the time and skill each one demands.” Here is how the two actually differ, the costs each side tends to hide, and a way to decide that does not depend on which camp posted last.

What the two words actually mean

Self-hosting here means you run the servers and the software: dedicated or rented machines — a Hetzner dedicated box, a rack of your own hardware, a Proxmox cluster — where you are responsible for the operating system, the hypervisor, patching, backups, networking, and recovery. You rent or own the metal; everything above it is yours.

Managed cloud means you rent an outcome rather than a machine. Cloudflare Workers running your code without a server to patch, a hosted database, a SaaS tool that replaces a system you would otherwise operate. You pay more per unit of raw compute and, in exchange, hand off the operational burden.

Most real setups are a blend. The question is rarely all-or-nothing; it is which workloads sit on which side of the line.

The cost that shows up on the invoice

On raw resources, self-hosting usually wins, and it is not close. A dedicated server with generous cores, memory, and disk can cost less per month than a modestly sized managed database alone. If your workload is steady and resource-hungry — large databases, media processing, big in-memory caches, predictable batch jobs — the metal is genuinely cheaper, sometimes by a wide margin, and the savings grow with scale.

That is the advantage that starts every self-hosting thread, and it is real. It is also only one line of the accounting.

The cost that does not show up on the invoice

Self-hosting moves cost off the invoice and onto your team’s time and skill. The bill gets smaller; the responsibilities do not disappear, they change owner.

• Operations become your job. Operating-system updates, security patches, certificate renewals, kernel upgrades, disk-space monitoring. Small tasks individually, unending in aggregate, and the day one is skipped is the day you learn why it mattered.
• Recovery is on you. When a disk fails or a host goes down, there is no support tier to escalate to. Your backups, your restore procedure, and your ability to execute it under pressure are the entire safety net. An untested backup is worth nothing here.
• Security is a standing duty. Exposed services need hardening, monitoring, and prompt patching. The responsibility that a managed provider quietly carries becomes visible and yours.
• It needs someone who knows how. Running a Proxmox cluster or a hardened Linux fleet well is a real skill. If one person on the team holds all of it in their head, that person is now a single point of failure — and a hiring and vacation problem.

None of this is an argument against self-hosting. It is the part of the price that the sticker does not show, and it is paid in hours and expertise rather than dollars.

The hidden costs on the managed side too

Managed cloud is not free of hidden costs; it just hides different ones.

• Metered pricing compounds. Per-request, per-gigabyte, and egress charges are trivial at small scale and can grow faster than expected as you do. A workload that was cheap to host can become expensive to host well.
• Egress and lock-in. Getting data out often costs money, and building deeply against one provider’s specific services raises the price of ever leaving. That switching cost is real even when you never exercise it.
• Less control. You take the platform’s limits, quotas, and occasional outages as given. When the provider has a bad day, you wait it out with everyone else, and your only lever is a support ticket.

The managed pitch — that you never think about the underlying machine — is true, and it is exactly why the costs are easy to underweight until a bill or an outage makes them concrete.

A framework for deciding

Rather than picking a side, sort each workload against a few questions.

How predictable and steady is the load? Steady, heavy, predictable workloads reward self-hosting, because you are paying for capacity you actually use around the clock. Spiky, unpredictable, or near-zero-baseline workloads reward managed, because you pay for what you use and let someone else hold the idle capacity.

How much operational skill and time do you have? This is the decisive question and the one most often skipped. If you have people who know infrastructure and the time to run it, self-hosting converts that capacity into savings. If you do not, self-hosting converts a cash cost into a time cost you cannot actually pay, and the savings are an illusion you notice at the worst moment.

How much does an outage cost you? For a workload where downtime is expensive, the managed provider’s operations team and redundancy may be worth every extra dollar. For an internal tool where an hour of downtime is a shrug, the calculus tips the other way.

How sensitive or specific is the workload? Data-residency requirements, unusual hardware needs, or a wish to avoid a particular provider can push toward self-hosting regardless of cost. A desire to move fast with a small team usually pushes the other way.

The most common healthy answer is a mix: self-host the steady, resource-heavy, well-understood workloads where the savings are large and the operational load is manageable, and use managed services for the spiky, security-sensitive, or undifferentiated pieces where the operational burden is not worth carrying. There is no prize for purity in either direction.

Where this lands in practice

Two patterns come up often. Teams already running VMware and rethinking it after licensing changes frequently look at Proxmox to reclaim control and cost — a real move with a real operational commitment, which we walk through on our VMware to Proxmox migration page. And teams tired of patching servers for workloads that do not need a server at all often move those pieces to Cloudflare Workers, where the operational surface largely disappears — the ground our Cloudflare work covers.

The right answer depends on your workloads, your team, and your appetite for operational responsibility, and it is genuinely different for different businesses. If you want an honest read on which of your systems belong on which side of the line, that is the kind of assessment described on our infrastructure page. Send us two paragraphs about what you run today and who keeps it running, and we will reply in writing within one business day.