CAPMOX Is Maturing Fast: What a Real Cluster API Provider for Proxmox Means Beyond Hetzner-Only Node Pools

Broadcom killed free ESXi when it folded VMware into a subscription-only model, and the homelab crowd didn't wait around to see if the new pricing would soften. They moved to Proxmox VE — free, Debian-based, and now the default answer to "what hypervisor do you run" in every homelab thread that used to say ESXi. That migration left a lot of self-hosters running real virtualization infrastructure on hardware they already own, with no path to the same git-push, HTTPS-in-minutes experience a Cluster-API-managed PaaS gives a Hetzner fleet — because until recently, there wasn't a Cluster API provider for Proxmox worth building against.

There is now. IONOS Cloud's cluster-api-provider-proxmox — CAPMOX — has shipped six releases since March 2025, and the most recent ones look less like a side project and more like a provider settling into a stable contract. That's a real claim worth checking against the actual changelog before deciding it changes anything for a fleet that currently only speaks to Hetzner's APIs.

The population this actually reaches is worth being specific about, too. It isn't "Kubernetes enthusiasts in general" — it's people already running Proxmox as their hypervisor of record, on hardware they bought and own, who have zero interest in renting a Hetzner box because renting was never the point of self-hosting for them in the first place. Proxmox's post-Broadcom rise put a lot of real compute into that category: spare rack servers, decommissioned enterprise gear, home NAS boxes doubling as VM hosts. A Cluster-API provider that talks to Proxmox is the difference between that hardware staying a pile of hand-managed VMs and it becoming a fleet a git-push PaaS can actually target.

"Matures" Checked Against the Changelog​

Here's the release history that backs the claim, pulled straight from CAPMOX's own release notes:

Two things stand out. First, the pace is real: six releases in fifteen months, with the last two landing within two weeks of each other in mid-2026, is an active maintenance cadence, not an abandoned repo with a green README badge. Second, the honest caveat the word "matures" needs: the API contract is v1alpha2. That's the second alpha contract CAPMOX has shipped — v0.8.0 broke compatibility with the original v1alpha1 API just over a year ago. A provider can be actively maintained and still be on a contract that reserves the right to break again before it reaches v1beta1. "Maturing" is the accurate word here. "Mature" would overstate what a still-alpha API surface actually promises.

How CAPMOX Actually Provisions a Node​

The mechanics are worth walking through concretely, because they're where the real comparison to CAPH — the Hetzner provider a bex-style fleet already runs — lives.

CAPMOX needs four things in place before it can turn a ProxmoxMachine object into a running node:

• A Proxmox API token, scoped to a dedicated user (the docs recommend capmox@pve with the PVEVMAdmin role) rather than a root credential.
• A VM template, built ahead of time with image-builder's Proxmox target and stored on a Proxmox node — CAPMOX clones from this template rather than booting a bare ISO.
• A Proxmox bridge (typically vmbr0) with a reserved IP range sitting outside any DHCP scope, since node addressing runs through the in-cluster cluster-api-ipam-provider-in-cluster project instead of DHCP.
• At least one SSH key in the machine spec — CAPMOX's own docs are blunt about this one: skip it and "the cluster will fail to provision."

Bootstrap itself runs through cloud-init, delivered via Proxmox's snippet mechanism, using the standard Kubeadm bootstrap provider (Flatcar images swap in Ignition instead, with a flag to skip the cloud-init status check). That's the same declarative shape CAPH uses against Hetzner's Cloud and Robot APIs — a machine spec goes in, a running, kubeadm-joined node comes out — but the prerequisites underneath it aren't interchangeable. Hetzner's Cloud API hands CAPH a load balancer as a first-class object. Proxmox has no equivalent, so CAPMOX ships kube-vip by default: a Layer 2 (ARP) or BGP virtual IP that always resolves to a healthy control-plane node, load-balancing the API server over IPVS on port 6443. It works, and it's built in rather than left as an exercise for the operator — but it's still a second HA mechanism a fleet has to understand and monitor, sitting where Hetzner's managed load balancer used to just be an API call.

It's Not the Only Provider Chasing This​

CAPMOX isn't the only living implementation. k8s-proxmox/cluster-api-provider-proxmox (CAPPX) takes a genuinely different approach — no template requirement at all; it boots from any image referenced directly in ProxmoxMachine.spec.image and applies cloud-config over a VNC websocket connection instead of Proxmox snippets. It's real and maintained, but pinned to the older CAPI v1beta1 contract, one generation behind CAPMOX's v1beta2 alignment. The earliest attempt, Rafael Fernández López's ereslibre/cluster-api-provider-proxmox, is archived and read-only since March 2021 — two commits, dead. Kamaji's Proxmox integration, for what it's worth, isn't a fourth competitor; its own docs are explicit that "the Proxmox Cluster API implementation is developed and maintained by IONOS Cloud," meaning it's CAPMOX underneath a different control-plane layer. For a fleet picking one provider to build against today, CAPMOX's newer API alignment and IONOS's release cadence make it the one worth betting on over CAPPX's template-free approach — but "worth betting on" and "settled ecosystem" aren't the same claim, and a provider choice made in 2026 could still be the wrong one a year out if CAPPX's model turns out to matter more than templates-first CAPMOX assumed.

What a Second Provider Actually Costs​

The TODO framing for this piece asks the right question directly: what does maintaining a second CAPI provider's node-image and networking assumptions cost, alongside CAPH's? Three concrete lines, not a hand-wave:

1. A second image pipeline. CAPH's Hetzner nodes and CAPMOX's Proxmox nodes don't share a template. Each needs its own image-builder target, its own patch cadence, and its own place in CI — a fleet operating both isn't running one golden image twice, it's running two golden images that happen to boot the same kubeadm join script.
2. A second networking model to operate, not just configure. kube-vip's ARP/BGP virtual IP has to sit on a subnet carved out of DHCP scope specifically for it, and it's now an in-cluster component a fleet has to monitor for split-brain and failover behavior — a genuinely different operational surface than calling Hetzner's load balancer API and trusting Hetzner to run it.
3. Living on an alpha contract. v1alpha1 broke a year ago; v1alpha2 is not guaranteed to be the last break before CAPMOX reaches v1beta1. A provider integration built against CAPMOX today has to budget for a migration the way v0.8.0 users already did once.
4. A node-pool abstraction that stops mapping cleanly to "region." Hetzner node pools map to a datacenter and server type a fleet can enumerate from an API. A Proxmox node pool maps to whatever cluster of physical hosts one operator happens to own — capacity planning, quotas, and "which node pool is this app allowed to land on" all become operator-specific facts a Hetzner-only control plane never had to model.

That fourth line is easy to undercount because it doesn't show up in a provider's changelog at all — it shows up the first time a fleet's own scheduling logic assumes every node pool is a fungible, API-enumerable pool of identical Hetzner server types, and a Proxmox pool breaks that assumption.

None of that is a reason to skip Proxmox support. It's the actual price of the thing the TODO asked about — not "should bex support Proxmox," but what supporting it costs beyond the marketing-page version of "just add a provider." The audience it unlocks is real and distinct from the Hetzner-renting crowd: self-hosters and on-prem operators who already run Proxmox on hardware they own, who want bex's git-push deploy experience on that hardware instead of a second cloud bill, and who were never going to be Hetzner Cloud customers in the first place. For that audience, three real operational costs — a second image pipeline, a second HA mechanism to run, and an alpha API to track — are the honest tradeoff against a genuinely new category of user a Hetzner-only fleet currently can't reach at all.

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

Sources​

• ionos-cloud/cluster-api-provider-proxmox on GitHub
• CAPMOX Releases
• CAPMOX Usage docs
• k8s-proxmox/cluster-api-provider-proxmox (CAPPX) on GitHub
• ereslibre/cluster-api-provider-proxmox on GitHub (archived)
• Kamaji — Proxmox VE Infra Provider docs
• kube-vip — Kubernetes Control Plane Virtual IP and Load-Balancer
• Cluster API Provider Hetzner (CAPH) — Introduction