1.5TB of RAM and 192 vCPUs for Under €600/Month: What a Hybrid Talos-on-Hetzner Build Validates About Splitting Control Planes From Workers

A builder published a number in March 2026 that should make every platform team stop scrolling: a hybrid Kubernetes cluster on Hetzner — Talos Linux on bare-metal dedicated servers for workers, VM-hosted control-plane nodes, stitched together over vSwitch with Cilium and Longhorn, running KubeVirt workloads — with 1.5TB of RAM and 192 vCPUs for under €600 a month. Not a cloud bill projection. A real cluster, real hardware, real invoice total.

The headline number is the hook, but it is not the point. The point is the shape: cheap, stable VMs for the control plane, cheap raw iron for the workers, one immutable OS across both. That is the exact hardware-tier split a Cluster API fleet on Hetzner (CAPH) already makes — and this build is an independent data point, not a vendor's math, for whether the split holds up. So let's do the honest thing: put the builder's numbers up front, rebuild them from Hetzner's price list, walk through what actually broke, and then ask where the round "bare metal is 4-5x cheaper" figure lands against third-party evidence.

The numbers, up front​

Here is the build as reported, converted to the unit costs that make comparisons possible:

Two things stand out immediately. First, the per-gigabyte RAM price — €0.39 — is the number that matters most, because memory is where cloud premiums bite hardest. Second, the control plane costs the builder essentially nothing incremental: a few small VMs, folded into the same €600. Keep both in mind; we will test them below.

Rebuilding the math from Hetzner's price list​

Trust, but verify against the price list. Current-generation Hetzner dedicated hardware gives us the cleanest independent check: a Hetzner AX102 — Ryzen 9 7950X3D with 16 cores / 32 threads, 128GB of DDR5 ECC, and 2× 1.92TB NVMe — lists at €119/month in Finland and €124 in Germany as of June 2026 (via Rajesh Medampudi's bare-metal breakdown). At €124, that machine costs ~€0.97/GB of RAM and ~€3.88 per thread per month.

Compare that to the build's €0.39/GB and €3.13/vCPU. The builder's numbers undercut current-gen list prices substantially on memory — roughly 2.5x cheaper per gigabyte. That gap tells its own story: this build almost certainly leans on older or auction-market machines, where Hetzner's Server Auction routinely prices previous-generation dual-Xeon boxes with big RAM configurations far below new-iron rates. There is nothing wrong with that — auction hardware is a legitimate, widely used capacity strategy — but it is the sensitivity variable the headline hides.

Rebuild this cluster on new AX-class iron and the monthly total roughly doubles; rebuild it on auction boxes and the builder's number is exactly what you would expect.

The control-plane side checks out cleanly. Small Hetzner Cloud VMs suitable for etcd and the API server cost single-digit euros per month each, and three of them for a HA control plane land under €30/month combined — under 5% of the build's total. The builder's "included in the €600" framing is fair: at this fleet size, the control plane is a rounding error, not a line item.

Verdict on the numbers: plausible and consistent with the hardware market, with one asterisk — the €600 total assumes bargain-hunted iron, not list-price iron. That asterisk matters for the 4-5x question we will settle at the end.

Why the split is the point​

The interesting decision in this build is not "Hetzner" or "Talos." It is the tiering: VMs for control planes, bare metal for workers. Each tier sits where it does for a concrete reason.

Control-plane nodes want stability, not muscle. etcd cares about low-latency, reliable disk writes and steady networking; the API server cares about availability. Neither benefits from 128GB of RAM or NVMe RAID. Small VMs on a cloud hypervisor — with live migration, snapshots, and a provider-managed network underneath — are a better home for that workload profile than a €124 dedicated box, and they cost an order of magnitude less. Kubernetes enforces the companion rule mechanically: control-plane nodes carry the node-role.kubernetes.io/control-plane:NoSchedule taint, which Talos applies by default, because a noisy workload can starve the very processes the whole cluster depends on. Physically separating the tiers makes that rule structural instead of aspirational.

Workers want the opposite: maximum cores, memory, and local disk per euro, with no hypervisor tax. That is precisely what dedicated servers sell. A KubeVirt worker in particular — running VMs inside pods — benefits from bare metal twice over: no nested virtualization penalty, and direct access to CPU features the hypervisor might mask. The builder running KubeVirt on Talos workers is a meaningful signal here, arriving the same year Sidero announced native hypervisor support in Talos itself: the VM-workload-on-Kubernetes story is converging, and bare-metal workers are its natural home.

Talos on both tiers is what makes the split operable rather than merely cheap. One immutable, API-driven OS image, no SSH drift, declarative machine configs — the operator manages two hardware tiers through one interface. That uniformity is doing quiet load-bearing work, and it is the part the hand-built version of this cluster has to replicate with discipline where a Cluster API fleet gets it from controllers.

What broke: VLANs, names, and two provisioning paths​

The build log's most valuable content is not the invoice total. It is the three problems the builder hit, because each one sits exactly on the seam between the two hardware tiers.

Problem one: VLANs between VM and bare-metal nodes. Hetzner Cloud VMs and dedicated servers live in different network worlds by default. Joining them into one cluster network means attaching the dedicated servers to a vSwitch and trunking a VLAN (commonly ID 4000) between the two sides, with each node carrying addresses from the routed subnet. This is documented territory — Pavel Hostim's MetalLB-on-vSwitch walkthrough covers the same plumbing — but it has a sharp edge the builder had to find: Cilium flushes all routes in table 200 on startup, which silently breaks vSwitch routing if your VLAN routes live there.

That is the kind of failure that presents as "networking works until the CNI restarts" and eats an afternoon. Any fleet making this split inherits this exact interaction between the CNI and the provider's VLAN plumbing.

Problem two: consistent naming across two provisioning paths. Dedicated servers come from the Robot API (or auction UI); VMs come from the Cloud API. Two APIs, two naming schemes, two sources of truth for which machine is which — and Kubernetes plus Talos want one coherent view of node identity. The builder had to impose naming discipline by hand across both paths. This is toil, not engineering: it works until someone provisions a replacement node at 2am and the naming convention is in a wiki page nobody opened.

Problem three: GitOps across the divide. The builder used Kluctl to keep cluster state declarative. That choice is correct — GitOps is the only sane way to operate a cluster you assembled from two provisioning systems — but notice what GitOps covers and what it does not: it reconciles Kubernetes state, not machine existence. If a bare-metal worker dies, Kluctl cannot order a new one from Robot. The machine layer stays manual.

These three problems share a shape: everything above the machines is declarative and reproducible; everything at the machine layer is hand-built and convention-dependent. Which brings us to the fleet question.

What a Cluster API fleet borrows — and skips​

A CAPH-managed fleet makes the identical hardware-tier split — and the build log reads, in retrospect, like an argument for managing it with Cluster API rather than by hand.

What CAPI borrows directly: the split itself is validated. Cheap VM control planes plus bare-metal workers is not a compromise the builder settled for; it is the shape a cost-conscious fleet converges on independently, and the builder's numbers confirm the control plane stays a rounding error at real scale. The Talos-on-both-tiers uniformity is validated too — and note that the ecosystem is meeting this pattern halfway, with community CAPH work adding explicit Talos flavors (see the hcloud-talos cluster template) so the OS layer is declarative from clusterctl onward.

What CAPI fixes: problem two and the machine half of problem three. MachineDeployments and the CAPH provider replace hand-imposed naming conventions with generated machine names tied to declarative specs, and node replacement becomes controller reconciliation instead of a 2am Robot order. The machine layer gets the same GitOps treatment the workload layer already had — which is exactly the gap the builder's Kluctl setup could not close on its own.

What CAPI does not fix: problem one. The vSwitch VLAN, the routed subnet, the Cilium route-table interaction — none of that disappears when machines are declaratively provisioned. CAPH has to configure the same provider networking, and the operator still needs to know that table 200 is spoken for. Anyone selling you "CAPI makes hybrid Hetzner trivial" is skipping the network seam. It makes the machine seam declarative; the network seam stays earned knowledge. Budget your runbook accordingly.

Where the 4-5x figure lands​

Now the question this post promised: do third-party numbers confirm or undercut the round "bare metal is 4-5x cheaper" claim? We can answer it precisely, because all three inputs are now on the table: the build's €600, Hetzner list prices, and current cloud memory pricing.

The like-for-like cloud comparison for 192 vCPUs and 1.5TB of RAM is three AWS r6i.16xlarge instances (64 vCPUs / 512GB each), at $4.032/hour — $2,943/month each on-demand in us-east-1 as of September 2026:

Read that table carefully, because it both confirms and reframes the folk figure. The 4-5x multiple is what you get only at three-year committed pricing — and only for the raw capacity, before a dollar of managed services. On-demand, the multiple for memory-heavy capacity runs past 13x. That lands well above the oft-cited "post-optimization costs still 3-5x bare metal" finding in the platform-engineering repatriation survey — which makes sense once you see the sensitivity variable: workload shape.

Memory-heavy capacity is where the cloud premium is steepest and bare metal wins biggest. Bursty, spiky, or mostly-idle workloads narrow the multiple; steady-state memory footprints widen it past anything a round number captures.

So the honest verdict: 4-5x is conservative for raw memory-heavy capacity and roughly right as a blended figure for a typical mixed PaaS fleet once managed services enter the picture. The build's numbers do not undercut the folk figure — they show it was already rounding down.

The takeaway for your fleet​

One builder, one invoice, three lessons. The VM-control-plane plus bare-metal-worker split is independently validated as the cost-optimal shape, with the control plane a rounding error at real scale. The machine layer is where hand-built clusters accumulate toil — naming conventions, manual replacement — and it is exactly the layer Cluster API exists to absorb. And the network seam between Hetzner's two worlds is the part no amount of declarative tooling makes trivial; it stays in your runbook no matter what provisions your machines.

If you are sketching a self-hosted fleet today, this build is the closest thing to a free reference architecture the community has published: copy the tiers, automate the machines, and respect the VLAN.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.