Dora NodaKarpenter made its name provisioning an EC2 node in 45 to 60 seconds — a number every AWS platform-engineering deck since 2023 has quoted. It's a real number, and it's also almost entirely about the EC2 API. Move that same "just-in-time node" promise onto Cluster API — the substrate any self-hosted PaaS actually uses to run on Hetzner, vSphere, Proxmox, or bare metal — and the number changes, because the thing standing between "pod is unschedulable" and "node is Ready" is no longer a single cloud vendor's API call. It's Cluster API's own machine lifecycle, running on whatever infrastructure provider sits underneath it.
Three projects now claim a piece of that answer: Cluster Autoscaler's Cluster API provider (mature, GA, the thing hundreds of clusters already run), karpenter-provider-cluster-api (an alpha proof of concept that borrows Karpenter's name but not yet its brains), and vCluster's Auto Nodes (a third path that sidesteps the question by putting Karpenter inside a virtual cluster instead of on top of CAPI). Here's what each one actually gets a Hetzner-backed fleet today, and which one a self-hosted PaaS should wire in first.
The number that matters: node-ready time on owned hardware, not EC2
The concrete comparison, stated up front: Karpenter's 45–60 second figure is measured against AWS's EC2 API on a warm AMI path — Karpenter calls EC2 directly, skips the Auto Scaling Group middleman, and the node joins fast because the image is already baked. Cluster Autoscaler's classic ASG-based flow on AWS trails it at 3–4 minutes for the same job, which is the gap Karpenter was built to close.
Neither number describes what happens on Cluster API against Hetzner, which is the substrate that actually matters here — bex's own roadmap lists "Cluster Autoscaler wiring" as an open line item, targeting Hetzner as its first Cluster API provider. Layer in the pieces that are actually measured:
| Stage | Typical time | Source |
|---|---|---|
| Hetzner Cloud API creates the VM, IP assigned | ~15–30 seconds | Hetzner's own provisioning is consistently benchmarked under 30s, often 15–20s |
| cloud-init runs, kubelet starts, node joins via kubeadm | ~30–90 seconds | Standard kubeadm-join overhead, independent of cloud |
CNI comes up, node flips Ready, pod actually schedules | ~15–30 seconds | Depends on CNI choice; Cilium/Calico both add a short settle window |
| Total: unschedulable pod → running pod on CAPH + Cluster Autoscaler | ~1.5–3 minutes | Composite of the above, not a single vendor benchmark |
That total lands closer to Cluster Autoscaler's own AWS-ASG number than to Karpenter's EC2 number — which makes sense, because on Cluster API, every provider goes through the same machine-creation choreography (CAPH's HCloudMachine reconcile, kubeadm bootstrap, node join) regardless of which autoscaler is asking for the node. The autoscaler doesn't skip that path; it just decides when to ask. So the honest framing for a Hetzner-backed fleet in 2026 isn't "Karpenter is 3x faster" — it's "the machine-provisioning floor is Cluster API's, not the autoscaler's, and no CAPI-based autoscaler beats it, alpha or GA."
The one place hardware physically changes the math is true bare metal via Metal3 or Tinkerbell — Ironic's PXE-boot-then-image-to-disk flow, or Tinkerbell's Boots/HookOS netboot, run for minutes per node, not seconds, because they're writing an OS to a physical disk instead of asking a hypervisor for a VM. If a self-hosted PaaS's autoscaling story assumes Hetzner Cloud VMs (as bex's CAPH-first roadmap does), the 1.5–3 minute range above is the honest floor. If it assumes real bare-metal PXE provisioning, budget minutes, not seconds, and don't let a Karpenter-branded product name imply otherwise.
What Cluster Autoscaler on Cluster API actually does
Cluster Autoscaler's clusterapi provider is the boring, load-bearing option: it watches MachineSet, MachineDeployment, and MachinePool objects for a pair of annotations —
cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size
cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size— and adjusts .spec.replicas up or down as pods go unschedulable or nodes sit idle. That's the entire scaling primitive: no custom CRD, no separate controller loop per cloud, just replica counts on objects Cluster API already reconciles. Scale-from-zero is supported, but only if the infrastructure provider publishes capacity annotations (CPU/memory/GPU/pod-count) on a zero-replica group — CAPH added this, so a Hetzner fleet can scale a MachineDeployment from zero, but it's provider-dependent, not automatic for every CAPI provider.
Cluster Autoscaler's bin-packing is comparatively unsophisticated: it consolidates by watching per-node requested-resource utilization against a threshold and evicting/draining underused nodes, one MachineSet at a time. It doesn't simulate whole-cluster pod placement before deciding what to remove. That's the tradeoff for maturity — CAPH reached its v1.0 GA in October 2024 after four years of production use across "hundreds of organizations" per its own release notes, and Cluster Autoscaler-on-CAPI has been the default recommendation in CAPH's docs the whole time. It works, it's boring, and boring is exactly what you want underneath a PaaS control plane deciding when to spend money on a new Hetzner box.
What Karpenter-for-Cluster-API doesn't do yet
This is the part worth being precise about, because "Karpenter" carries three years of AWS reputation for smart bin-packing and consolidation that karpenter-provider-cluster-api has not earned yet. The project's own README calls it "an experimental proof of concept" at v0.2.0, and lists what's still missing in plain terms:
- Drift detection — Karpenter-on-AWS notices when a running node no longer matches its
NodePoolspec and retires it; the CAPI provider doesn't do this yet. - Disruption and consolidation — the whole-cluster bin-packing simulation that lets Karpenter merge underused nodes and pick the cheapest instance shape that satisfies pending pods isn't implemented. Today the CAPI provider does basic node creation and deletion — the replacement for
MachineDeploymentscaling, not yet the replacement for Karpenter's placement intelligence. - Cost integration — Karpenter-on-AWS picks instance types by price; the CAPI provider has no pricing signal to reason about, because Cluster API providers don't expose one uniformly.
So today, adopting karpenter-provider-cluster-api over Cluster Autoscaler buys a different API surface (Karpenter's NodePool/NodeClaim CRDs instead of annotated MachineDeployments) — not better bin-packing, not faster nodes, and not consolidation. The node-provisioning floor is identical, because both call the same Cluster API machine-creation path underneath. The maintainers' own stated goal is "a standard release cycle and production-ready" provider, which is aspirational language, not a shipped milestone — there's no GA date attached to it as of this writing.
vCluster's Auto Nodes (GA'd across its Private Nodes model, announced in September 2025) is a third, structurally different path worth naming precisely so it doesn't get conflated with the other two: it embeds a real Karpenter operator inside each virtual cluster, and that operator's NodeClaims get fulfilled by pluggable node providers — Terraform/OpenTofu, AWS/Azure/GCP quickstarts, NVIDIA BCM, or KubeVirt VMs on bare-metal hosts. That does get you Karpenter's actual consolidation logic today, but only inside vCluster's virtualization layer, and it provisions VMs on a bare-metal host pool you still have to run — it doesn't answer "how fast does Cluster API alone get me a Hetzner node," it answers a different question about tenant isolation.
Why the provisioning floor matters more on owned hardware than on EC2
On AWS, shaving Karpenter's 45–60 seconds down further mostly buys latency — EC2 bills by the second either way, so a slow scale-up wastes wall-clock time, not much money. On a Hetzner-backed fleet, the same 1.5–3 minute node-ready window interacts with a different cost model: Hetzner Cloud bills hourly, and dedicated boxes are a flat monthly fee regardless of utilization, so the penalty for scaling up "just in case" isn't a per-second EC2 charge — it's an idle machine sitting at the bottom of Cluster Autoscaler's scale-down threshold for however long that threshold is configured, still costing the same as a busy one. That makes the scale-down side of Cluster Autoscaler's annotation-driven MachineDeployment shrinking — not the scale-up latency Karpenter markets — the lever that actually controls spend on owned hardware. A self-hosted PaaS tuning autoscaling for Hetzner should weight the aggressiveness of that scale-down threshold at least as heavily as node-ready time, since a fleet that provisions fast but drains slow just trades one kind of waste for another.
The call: wire Cluster Autoscaler now, watch Karpenter-for-CAPI, don't block on it
For a self-hosted PaaS deciding what to wire into its own control plane this year, the decision tree collapses to one branch: Cluster Autoscaler's Cluster API provider is the only one of the three with a GA track record on Hetzner specifically, four years of production mileage through CAPH, and zero missing-feature caveats in its own documentation. Karpenter-for-CAPI, despite the name recognition, is pre-alpha-in-spirit — a basic create/delete loop wearing Karpenter's CRDs, with the actual smart-scheduling engine explicitly called out as unbuilt. vCluster's Auto Nodes solves a real problem, but it's tenant-isolation-shaped, not "which autoscaler sits under my Cluster API fleet"-shaped.
That's also, concretely, the reasoning behind item 3 on bex's own roadmap — "Cluster Autoscaler wiring" is scoped to the mature CAPI provider, not the alpha Karpenter one, precisely because the alpha project doesn't yet do anything Cluster Autoscaler doesn't already do, on the same Hetzner machine-creation path either way. The moment karpenter-provider-cluster-api ships disruption and consolidation against a stable release cycle, revisit — a smarter bin-packer sitting on the identical CAPI plumbing is a straightforward swap, not a redesign. Until then, tracking it costs nothing; blocking a working autoscaler on it costs a PaaS its whole reason for having one.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with Cluster API doing the same machine-lifecycle work described above underneath it. Star the repo on GitHub or deploy your first app today.
Sources
- karpenter-provider-cluster-api — project README, status, and feature-gap list
- Cluster Autoscaler — Cluster API cloud provider — annotation-driven scaling mechanism
- Cluster API Provider Hetzner (CAPH) — GA status, cluster-autoscaler integration guidance
- Scaling machines with CAPH — GitHub Discussion #1222
- vCluster Auto Nodes announcement
- Metal³ Provisioning and Deprovisioning guide — Ironic PXE-boot-to-disk flow
- Tinkerbell — Boots/HookOS netboot architecture
- Karpenter vs Cluster Autoscaler: 2026 Comparison Guide — EC2-path timing figures
- Hetzner Cloud Review 2026 — Better Stack Community — server provisioning speed