The Economics of Owning vs Renting
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 Server types and sizing and reduce cloud costs with Syself .
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 cluster upgrade 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 run as your own services 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 bare-metal base and cloud workers : 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 run your own services .
Owning the server also makes sovereignty possible, because the account and the keys are yours. For the numbers applied to your own bill, see reduce cloud costs with Syself .
What You Own, What Syself Manages
Hetzner runs the hardware, Syself runs the platform and ships the compliance evidence, and you own your workloads and your audit.
The security model
Every connection into a Syself Autopilot node authenticates on its own, so a node runs safely on the public internet with no private network. You still configure SSH access and pod-to-pod segmentation.