Dora NodaYour Hetzner-only fleet is humming. One clusterctl command provisions a node, MachineHealthChecks replace the sick ones, and the monthly invoice is a single predictable number. Then a tenant asks for an H100 in Paris for a three-week inference push — and suddenly your single-provider story has a gap you cannot price your way out of. Hetzner sells excellent bare metal, but it does not sell every accelerator, in every region, on hourly billing.
That is the exact moment Scaleway's Cluster API provider starts looking interesting. Scaleway ships and maintains its own CAPI infrastructure provider — scaleway/cluster-api-provider-scaleway (CAPS) — installed with clusterctl init --infrastructure scaleway, giving the same declarative machine-lifecycle model CAPH already applies to Hetzner a second EU-native target. The question is not whether CAPS works. It is whether a small platform team should operate two infrastructure providers instead of one — and what that second provider concretely costs. Here is the verdict up front, with the evidence behind it in the sections below:
| Your situation | Verdict | Cost signal |
|---|---|---|
| All tenants fit on CPU nodes plus one GPU type Hetzner sells, in regions Hetzner serves | Stay single-provider on CAPH | A second controller, image pipeline, and upgrade matrix with no workload to justify them |
| Tenants need H100/L40S-class GPUs hourly, or capacity in Paris/Amsterdam/Warsaw specifically | Add CAPS as an opt-in second target | Hourly GPUs from ~€2.52/hr beat a €889/mo fixed box below ~50% utilization; verify Paris/Amsterdam/Warsaw stock first |
| You want one cluster spanning Hetzner and Scaleway workers | Rethink the design — CAPI does not do that | A ScalewayCluster owns its PrivateNetwork and control plane; multi-provider means separate clusters per provider, not mixed node pools |
The rest of this post covers what CAPS actually is, where Hetzner-only falls short, the five line items a second provider adds to your ops bill, and the decision rule for when it pays off.
What CAPS actually is (and is not)
CAPS is a standard CAPI infrastructure provider: a controller plus ScalewayCluster / ScalewayMachine CRDs that reconcile Scaleway Instances, PrivateNetworks, and load balancers from declarative manifests. You bootstrap a management cluster, run clusterctl init --infrastructure scaleway, and the provider lands in its own caps-system namespace next to capi-system — the same shape as CAPH's caph-system install, which current docs show tracking CAPI v1.13 with infrastructure-hetzner v1.0.7. CAPS publishes a compatibility table of provider versions against CAPI versions, and its v0.2.0 release implemented the CAPI v1beta2 contract while graduating its own CRDs to v1alpha2 with automatic migration from v1alpha1. In other words: maintained, versioned, and following upstream contracts — not a weekend fork.
What it is not is Scaleway's recommended way to run Kubernetes. Scaleway sells two managed offerings — Kapsule (clusters in Scaleway regions) and Kosmos (a multi-cloud control plane that can reach outside them) — with a shared control plane that is free and dedicated ones from around €0.11/hr, across Paris, Amsterdam, and Warsaw. CAPS is the self-managed alternative: you keep the control plane, the upgrade cadence, and the failure modes, and in exchange your clusters behave like every other CAPI cluster in your fleet — same GitOps flow, same MachineDeployment semantics, same audit trail. Choose CAPS when "one declarative fleet API across providers" matters more than "never think about the control plane."
One architectural fact shapes everything below, and it comes from a team that tried to blur the line: Tuist's platform docs note that upstream CAPS models a Scaleway-infra cluster in which ScalewayCluster owns the PrivateNetwork and control plane — so a CAPS worker pool cannot simply attach to a HetznerCluster. Each provider owns whole clusters. Internalize that before sketchy whiteboard diagrams promise a single cluster with Hetzner control planes and Scaleway GPU workers.
Where Hetzner-only falls short
Three gaps, in decreasing order of how often they actually bite.
Accelerator catalog. Hetzner's GPU story is its GEX range — most recently a GEX131 pairing a Blackwell RTX PRO 6000 (96 GB) with dedicated hardware at €889/month. That is a fine box for sustained workstation-class inference, and monthly pricing rewards keeping it busy. Scaleway's catalog plays a different game: L40S, L4, H100, and B300-SXM instances on hourly billing starting around €2.52/hr, aimed at tenants whose GPU need is bursty, experimental, or tied to a specific CUDA-memory profile Hetzner does not stock. Neither catalog dominates the other; they price different utilization shapes. Market trackers put H100 rentals roughly in the $1.80–$4/hr band, so a full month of one H100-class card at those rates runs ~$1,300–$2,900 — two to three times the GEX131's flat fee.
The honest comparison is therefore never "which GPU is cheaper" but "at what utilization does hourly beat monthly": at €2.52/hr against €889/mo, the breakeven sits near 48% utilization. Below it, hourly Scaleway wins; above it, the fixed Hetzner box wins. A tenant doing a three-week inference push and then going quiet is the textbook CAPS workload; a tenant training around the clock is the textbook reason to stay put.
Region map. Scaleway operates Paris, Amsterdam, and Warsaw — three EU jurisdictions with Kapsule/Kosmos available in each. If a tenant's data-residency story names France or the Netherlands specifically, or their users cluster around those metros, a CAPH-only fleet has no declarative answer. Note the reverse is equally true: Scaleway's three regions are a smaller map than Hetzner's footprint, so CAPS extends your map in specific directions rather than replacing it.
Sovereignty posture. Both vendors are EU-owned — Hetzner in Germany, Scaleway in France under Iliad — so this is not a "leave the hyperscalers" argument. It is a second-order one: some tenants need a named second EU jurisdiction for failover, procurement checklists that ask for multi-vendor sourcing, or simply leverage in the next contract negotiation. "The platform can run on more than one EU-owned cloud" is a real answer to those buyers, and it is worth exactly as much as your pipeline of such buyers — no more.
What the second provider concretely costs
Adding CAPS is not one decision; it is five new line items. Price each before committing.
1. A second controller to operate. caps-system joins caph-system on every management cluster: another deployment to monitor, another RBAC surface, another log stream in your runbooks. Small in steady state, but it is permanent overhead, not setup cost.
2. A doubled upgrade matrix. CAPS versions against CAPI versions in its compatibility table; CAPH has its own. Every CAPI core or Kubernetes minor upgrade now needs validation against two provider/controller combinations instead of one, including the CRD migrations each provider occasionally ships (CAPS's v1alpha1-to-v1alpha2 migration being a recent example). Budget the pre-flight, not just the rollout.
3. A second machine-image pipeline. CAPH provisions via Hetzner's rescue/installimage flow against Robot and HCloud APIs; CAPS builds Scaleway images with different tooling, drivers, and GPU base images. Two pipelines means two places where a driver update, a kernel bump, or a CUDA version pin can break provisioning — and GPU images break more often than CPU ones.
4. Per-provider networking and credentials. Because each provider owns whole clusters, multi-provider means separate workload clusters joined by design you now own: cross-cluster service discovery, a global ingress or DNS-weighted split, and replicated secrets for two API surfaces (Hetzner Robot + HCloud tokens on one side, Scaleway project credentials on the other). Provisioning now has two failure domains with two status pages.
5. A second node-pool cost model. Monthly dedicated billing (Hetzner) and hourly cloud billing (Scaleway) need different autoscaling and budgeting logic: scale-to-zero aggression that saves real money on hourly GPUs is pointless churn on a flat-fee box, while utilization alerts tuned for monthly hardware will page needlessly on hourly bursts. Run the breakeven math per pool — the ~48% figure above moves with every price change — and revisit it whenever either vendor reprices.
None of these is a veto. Together they are roughly a quarter to a half of an operator's ongoing CAPI attention, which is why the default answer stays single-provider until a workload on the other side justifies it.
The decision: stay single or go dual
Apply this rule in order, and stop at the first line that fires:
- A tenant needs an accelerator or region CAPH cannot serve. Hourly H100/L40S/B300, Paris/Amsterdam/Warsaw placement, or a named second EU jurisdiction — adopt CAPS scoped to exactly those workload clusters. This is the case the verdict table prices: bursty GPU work below breakeven utilization is cheaper hourly, and no amount of single-provider discipline conjures a region you do not operate in.
- No such tenant exists, but the pipeline is full of them. Stand up CAPS on a non-production cluster, validate the image pipeline and upgrade matrix, and keep it warm. The cost is bounded; the option value is real.
- Neither. Stay on CAPH. Revisit when a contract, not a conference talk, demands it.
The deeper point generalizes beyond these two vendors. Cluster API's provider model makes the second provider dramatically cheaper than the first — same Cluster/MachineDeployment API, same GitOps tooling, same mental model — while the per-provider details (images, networks, credentials, billing shapes) keep it from ever being free. That is the right way to read CAPS: not as pressure to leave Hetzner, but as a priced option on flexibility, worth buying the moment a tenant's GPU or region requirement pays its premium.
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.
