Dora NodaVultr announced Cluster API compatibility for its Kubernetes Engine in October 2024 — nearly two years ago, not last week. That timing matters, because the interesting question was never the announcement. It is what two years of a second managed cloud speaking the same declarative provisioning language actually proves: Cluster API standardizes how you ask for infrastructure, and precisely nothing about what the answer costs, where it runs, or who owns the metal underneath.
So here is the verdict up front. A managed cloud adopting CAPI is a genuine validation of the API as the emerging standard for programmatic infrastructure — the Cluster API Book now lists Vultr alongside Hetzner, Scaleway, Equinix Metal, and dozens of others. But for a platform deciding where its fleet lives, the standard was never the hard part. The bill, the regions, and the ownership model still decide.
And on all three, the two providers are barely the same product.
Same API, different bill
Take a representative small fleet — three workers in the 2-vCPU class, one load balancer, a modest block-storage slice — expressed the CAPI way on both sides. Same Cluster and MachineDeployment shapes; different everything else:
| Line item | Vultr VKE (managed, CAPI-compatible) | Hetzner Cloud (CAPH, self-managed) |
|---|---|---|
| Control plane | $0 — Vultr charges no management fee (AWS bills ~$73/mo per EKS cluster for comparison) | $0 — you run it yourself on the management cluster; the cost is your ops time, not an invoice line |
| 3× workers, ~2 vCPU class | 3× High Frequency 2 vCPU / 4 GB at | 3× CCX13 2 vCPU / 8 GB at €42.99/mo = ~€129/mo post-June-15-2026 pricing — dedicated vCPU, double the RAM, roughly 2.7× its own January price |
| Load balancer | ~$10/mo per instance | Hetzner LB from a few euros/mo (plan-dependent) |
| Egress | Pooled per-plan bandwidth plus account allowance; metered past it | 20 TB included per server on most cloud plans; flat and boring |
| Regions available | 32 locations across six continents (Vultr's own figure) | 6 (Germany ×2, Finland, US ×2, Singapore) |
Two honest caveats before anyone screenshots this table. First, the worker rows are not core-for-core identical: Hetzner's CCX13 is dedicated vCPU with 8 GB against Vultr's shared high-frequency 4 GB, so Hetzner brings more machine per line even at the higher post-hike price — and Hetzner's shared CX line would undercut both if you do not need dedicated cores. Second, catalog prices move; Hetzner moved twice in 2026 alone (April's broad +30–37%, then June 15's dedicated-line surgery that this blog covered line by line).
The table is a snapshot with named plans so you can re-run it, not a timeless scoreboard.
What "CAPI-compatible" standardizes — and what it cannot
The portable part is real and worth naming precisely, because it is the part your manifests feel:
- Portable:
Cluster,MachineDeployment,KubeadmControlPlaneshapes; rollout semantics (create-new, wait-Ready, delete-old);clusterctlworkflows; the mental model your team learns once. - Not portable: server-type names and what silicon sits behind them; per-GB bandwidth and what "included" means; load-balancer and block-storage behavior and pricing; GPU availability per region; support response when provisioning fails at 3 AM.
That split is why multi-provider projects like k0rdent — covered on this blog — treat "one API surface across CAPA, CAPZ, CAPG, CAPO, and more" as the asset rather than price parity. The win is operational: adding a provider becomes a ClusterTemplate plus credentials instead of a second platform to learn. The bill stays stubbornly per-provider, and anyone promising otherwise is selling the standard's virtues against the metal's invoice.
The adoption signal is real anyway
Do not mistake the economics for a dismissal. A mainstream managed cloud choosing Cluster API as its management interface — rather than a bespoke console-first API with a Terraform provider bolted on later — is a strong standards signal, and it compounds:
- The official provider list keeps growing past the hyperscalers into exactly the independent-cloud tier a self-hosting story cares about: Hetzner via Syself's CAPH, Scaleway, Equinix Metal, and now Vultr as a managed offering rather than a DIY provider repo.
- Fleet-management layers are standardizing one level up: one deployment shape provisions against many providers, distinguished by template and credential.
- Each new CAPI-compatible endpoint lowers the cost of the second provider specifically — which is the only provider switch that ever actually happens, since nobody migrates off their first provider for fun.
In other words: CAPI won the interface war among the clouds that matter to this audience. That is worth saying plainly even while the rest of this post argues it does not settle the fleet question.
Own vs rent: why the bet stays bare metal you own
Here is the sensitivity analysis the single-table snapshot cannot give you. Scale the fleet and vary the egress, and the two models diverge instead of converging:
- At 3 nodes with light egress, managed VKE and Hetzner cloud are the same order of magnitude — tens of dollars apart depending on which worker family you pick. Convenience wins here; rent.
- At 30 nodes, the per-node rental margin compounds every month with no equity at the end. Owned Hetzner dedicated boxes (an AX-class machine from ~€40/mo in third-party comparisons, against Vultr bare metal from ~$120/mo) amortize to a fraction of rented-node cost — and Hetzner's 2026 hikes, painful as they were, narrowed that gap without closing it.
- Under heavy egress, flat included bandwidth pulls away from metered bandwidth at exactly the workload shape a PaaS serves: many small tenant apps each pushing bytes. Per-plan pooled allowances are fine until they are not, and "until they are not" arrives as a surprise invoice rather than a capacity plan.
Run the rough monthly totals to feel the compounding — per unit of capacity, not per box. Thirty rented workers at ~$24 each is ~$720/mo of 2-vCPU/4-GB slices, before load balancers, storage, and metered egress, every month, adjusting upward whenever the catalog does. The equivalent capacity in owned dedicated hardware consolidates onto a handful of dense boxes (a ~€40/mo AX-class machine carries roughly 6 cores and 64 GB — the work of many small slices), each with its own 20 TB traffic allowance, so the egress row that grows on the managed side stays flat on the owned side.
These are estimates from named catalog plans, not quotes — re-run them with your own shapes. But the direction survives every plausible input: rental margins compound with scale, ownership amortizes with it.
There is a second cost the standard cannot standardize away: operating two providers is still operating two providers. Machine templates, image pipelines, and quota management differ per cloud; support relationships and bandwidth contracts are per-vendor; and every incident now starts with "which provider is this on." CAPI shrinks that overhead from "learn a second platform" to "maintain a second template set" — a real saving, and exactly the k0rdent-style consolidation win — but the template set still needs an owner. Budget one before promising multi-cloud on the strength of an API.
The through-line: CAPI compatibility makes a managed node pool operable the same way, but it is still a node pool you rent. Owning the metal is a different financial instrument — capex-like amortization with a floor — and no API standard converts one into the other. A platform whose whole pitch is flat pricing on owned hardware should cheer the standard and keep buying the servers.
Where a second CAPI provider genuinely earns its place
Single-provider honesty requires naming the exceptions. A second CAPI-compatible endpoint is worth its complexity when:
- Sovereignty or region coverage demands it. Six regions cannot serve users in São Paulo or Sydney; 32 locations can. No pricing table fixes physics.
- GPU availability dictates it. When the question is which cloud actually has accelerators allocatable this quarter, the provider with stock wins regardless of API elegance.
- Burst overflow needs a home. A CAPI-shaped spillover target you only pay for during peaks is precisely the "second provider you never migrate to" use case the standard makes cheap.
Note what all three share: they are about reach, not price. You add Vultr the way you add a second datacenter — for coverage — not the way you switch Transatlantic carriers for a cheaper per-minute rate.
The shape of the answer
Vultr speaking Cluster API since October 2024 proves the interface bet. The fleet bet — owned bare metal, flat bandwidth, one provider operated well — survives it unchanged, with three well-lit doors to a second provider when reach demands it.
Sources: Vultr, "Introducing Cluster API Support for Vultr Kubernetes Engine" (October 10, 2024) and VKE Cluster API docs; Cluster API provider list; Hetzner repricing figures via this blog's August 2026 fleet-economics coverage; Vultr catalog worker/LB rates via widely-quoted third-party 2026 comparisons (spot-check before budgeting); region counts via Vultr's announcement (32) and Hetzner's public cloud regions (6).
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.
