Skip to main content

The Economics of Owning vs Renting

Inspect 1.36

Owning your servers costs far less than renting the equivalent cloud compute. The sticker price is only part of it, because renting adds costs the per-core rate does not show. A cloud vCPU is a slice of a shared physical CPU, not a whole one. Traffic that leaves the provider's network is billed per gigabyte. Each managed control plane carries a monthly fee. When you own the server, you pay none of these. This page explains why the gap exists; for current figures, see and .

vCPUs and CPU steal#

Renting a vCPU means you share a physical core with other tenants. A vCPU is one hardware thread of a core, not a whole machine.

Providers sell more vCPUs than the box has physical threads. This is oversubscription. It works because the provider counts on tenants not all peaking at the same time.

When too many tenants peak at once, the hypervisor hands your CPU time to another tenant. This shows up as CPU steal: the time your workload waits while another tenant uses the shared core.

CPU steal makes your workload unpredictable. The same benchmark returns different numbers from one day to the next, and latency spikes. The steal itself is hard to see, because it does not appear in your own profiler.

Some clouds offer a dedicated-vCPU tier with pinned threads and no oversubscription, so no CPU steal. It costs much more than a dedicated server, a hypervisor still sits between you and the CPU, and the network port is still shared with other tenants.

A dedicated server has no hypervisor between you and the hardware. You get all the cores, all the threads, the full cache, and the real boost behavior, with no other tenants. Workloads that keep their cores busy, such as a database, a CI fleet, batch jobs, or inference, run at a fraction of the cloud price, and performance stays the same day to day.

Egress costs#

Egress can be the largest line on a cloud bill, and it is the easiest one to miss. Egress is the traffic that leaves the provider's network: responses to your users, backups sent offsite, model downloads, media.

Hyperscalers, the AWS, Azure, and Google Cloud class of providers, charge for egress per gigabyte. The rate looks tiny per gigabyte, but real workloads move terabytes, so the monthly total is large, often larger than what you save on compute.

A Hetzner dedicated server has an unmetered port: a flat link with no per-gigabyte charge, where the only limit is how fast the port runs. Cloud servers include some traffic and then bill the overage, and the included amount is smaller in some regions, so check the allowance for your location.

Managed control-plane fees#

Managed Kubernetes adds a second bill that has nothing to do with hardware: a per-cluster fee for the control plane. You pay it, on every cluster and every month, for an API server and etcd you do not manage yourself.

Some managed offerings also charge extra once a Kubernetes version ages out of standard support. The cluster is not upgraded for you and nothing breaks; the rate just goes up while you keep running the old version.

When you own the machines, the control plane runs on nodes you already pay for. There is no per-cluster meter and no rate change when a version ages. On Syself Autopilot, Syself does the upgrade and it does not change your bill. Every upgrade path is tested before release, and the replaces nodes one at a time from a new immutable image.

The costs of owning#

Owning saves money, but it also takes work.

A fleet of dedicated servers needs someone to build and patch the OS, track and patch CVEs, watch for failing disks and NICs, replace dead machines, prove upgrade paths, and solve storage and high availability. Skip that work and patches fall behind, dead hardware stays in the fleet, and upgrades get missed.

Syself Autopilot takes that work over. The servers stay in your own Hetzner account. Syself runs the lifecycle on top: the immutable node OS is built and tested before release, every machine boots only on that verified image, and a failed node is replaced rather than repaired.

You still own the layer above the platform: the databases, queues, and caches you with standard operators. Capacity planning stays yours too. A dedicated server is a monthly commitment with a setup fee and a provisioning lead time, not a cloud instance you start in seconds and shut down an hour later.

When to own and when to rent#

Run your steady load on bare metal you own. Rent for burst.

Own when the work keeps machines busy: base load around the clock, databases on local NVMe, CI, GPU and inference, high-egress workloads, and long-lived services. There the savings on compute, egress, and the per-cluster fee add up every month.

Rent when the work is spiky or short: preview environments, a job that needs a machine for an hour, capacity you cannot predict. That is why most Syself Autopilot clusters mix a : the base carries the steady load, the cloud workers absorb the burst, and both run the same immutable OS in one cluster.

You only get these savings if you run the services yourself instead of renting them back one by one, each with its own markup. See .

Owning the server also makes possible, because the account and the keys are yours. For the numbers applied to your own bill, see .