Proxmox VE Evaluations Up 340%: What the VMware Exodus Means for Your Next Cluster API Provider

VMware bills went up 10x. Proxmox evaluations went up 340%. The two numbers are the same story.

In November 2023, Broadcom closed its $61 billion VMware acquisition and killed perpetual licenses. By early 2025 it had imposed a 72-core minimum purchase floor and bundled subscriptions that European customers now report pushed bills 800 to 1,500 percent higher. AT&T sued after being quoted a 1,050 percent increase. In the same window, Gartner reported Proxmox VE evaluations jumped 340 percent year-over-year, and market-share trackers now put Proxmox at 21 percent of the hypervisor market in 2026 — up from 12 percent in 2024, with VMware sliding from 48 percent to 31 percent.

On November 19, 2025, Proxmox VE 9.1 shipped native OCI image support: pull any image from Docker Hub or a private registry straight into the Container Templates pool and run it as an LXC container — no Docker daemon, no VM wrapper. The feature is real, useful, and narrower than the headline suggests.

If you run a self-hosted PaaS on Cluster API today, you probably run CAPH against Hetzner. The question this post answers up front is whether that migration wave and that new LXC trick justify adding CAPMOX — the Cluster API Provider for Proxmox — as a second infrastructure target, and whether OCI-as-LXC is a shortcut for your build pipeline or a parallel format you will have to carry separately.

The short answer: CAPMOX is a credible second target for teams that already own Proxmox hardware — homelabs, office servers, and EU-sovereign edge sites — but it is not a drop-in replacement for CAPH's cloud API maturity. And OCI-as-LXC is not a Dockerfile replacement; it is a lightweight path for single-process services that happens to consume the same artifact your Dockerfile pipeline already publishes.

The Broadcom bill shock in numbers​

The VMware story did not start with a price sheet. It started with a license-model change.

• November 2023: Broadcom closes VMware. Perpetual licenses are terminated within weeks. Everything moves to bundled subscriptions.
• December 2023: End of standalone vSphere; products consolidated into Cloud Foundation and vSphere Foundation bundles.
• April 10, 2025: 72-core minimum purchase floor takes effect — a floor that forces a small cluster to pay for cores it does not have.
• H1 2025–H1 2026: Renewal quotes land. European lobby CISPE and its enforcement arm ECCO report customer increases of 800 to 1,500 percent. AT&T's filing discloses a projected 1,050 percent jump before Broadcom settled. The pattern matches what Gartner warned about after Broadcom's CA and Symantec deals: dramatic cost increases at renewal with limited negotiation leverage.

Gartner's evaluation surge measures intent, not installed base, but the installed-base numbers have followed. One independent 2026 landscape tracked:

Proxmox absorbed the majority of the migration, but the rest of the open ecosystem grew too. The driver is not feature parity with vSphere at the high end — it is a cost curve that stopped being negotiable.

For a Cluster API fleet, this matters because the fleet's hardware assumption is now in play. Two years ago the default answer for "where do I put my nodes" was Hetzner Cloud. Today a meaningful fraction of the teams asking that question already own Proxmox servers — in a closet, a colo, or an office that used to run VMware. That changes the provider calculus from "which cloud API is cheapest" to "can I reuse the hardware I already have."

What Proxmox VE 9.1 "OCI as LXC" actually does​

Proxmox VE 9.1 (Debian 13.2 Trixie, kernel 6.17.2, QEMU 10.1.2, LXC 6.0.5) added one clearly scoped feature: create LXC containers from OCI images.

The flow is:

1. In the Proxmox UI, go to Datacenter → Storage → Container Templates → Pull from OCI Registry, or call the new PVE API endpoint POST /nodes/{node}/storage/{storage}/oci-registry-pull.
2. Point it at any OCI-compliant registry — Docker Hub, GHCR, a private registry — and pull an image tag.
3. Proxmox converts the image layers into a local Container Template (a vztmpl tarball) stored in the local storage pool.
4. Create an LXC container from that template with pct create. The container's runtime is still LXC, not Docker or Podman. The image's entrypoint and command are reproduced inside the LXC rootfs.

The Terraform provider for Proxmox has an open feature request tracking the same endpoint as a proposed proxmox_virtual_environment_oci_image resource. The community pve-oci-compose and proxmox-lxc-compose helpers already wrap the pattern in compose-style YAML, and the API surface is stable enough that third-party launchers treat it as declarative.

What it is not:

• Not Docker inside Proxmox. There is no Docker engine, no containerd shim, and no docker-compose compatibility layer. If the image expects a Docker-specific mount or privileged operation, it will behave differently under LXC's stricter isolation.
• Not a VM replacement for heavy workloads. Application-container support shipped as a technology preview. Unprivileged LXC remains the recommended mode, which limits certain kernel operations. Stateful or kernel-module-dependent workloads still belong in a proper QEMU VM.
• Not a build-cache. Each pull flattens the OCI layers into a single template. Incremental layer reuse, multi-stage build semantics, and build-time secrets are still Dockerfile concerns that happen outside Proxmox.

The honest description: Proxmox taught its container stack to consume the registry ecosystem's artifact format without forcing every service to wrap itself in a full VM + Docker stack first. That is a genuine operational simplification for lightweight services — not a new packaging standard.

CAPMOX today: what a second Cluster API target actually looks like​

The Cluster API Provider for Proxmox (CAPMOX, maintained as ionos-cloud/cluster-api-provider-proxmox) is the counterpart to CAPH (Cluster API Provider Hetzner) for on-prem hypervisors.

Installing it follows the same clusterctl contract as any Cluster API provider:

source capmox.env
clusterctl init --infrastructure proxmox --ipam in-cluster \
  --control-plane kubeadm --bootstrap kubeadm

You create a Proxmox API token (pveum user add capmox@pve, pveum aclmod, pveum user token add capmox@pve capi --privsep 0), store it as a Kubernetes secret, and CAPMOX reconciles ProxmoxCluster, ProxmoxMachine, and ProxmoxMachineTemplate resources into QEMU VMs and, where configured, LXC-styled resources.

Compared to CAPH at feature level:

The honest gaps, drawn from the project's own open issues, matter for a PaaS operator:

• ClusterClass dry-run webhook: CAPMOX's ProxmoxMachineTemplate validation webhook has historically rejected topology-controller dry-run applies, which blocks ClusterClass-driven upgrades that CAPV, CAPA, and CAPD already handle. The fix is known and tracked, but it is the kind of provider-immaturity bug a second fleet will hit on day one.
• Multi-node Cloud-Init injection on shared storage: Deploying across multiple Proxmox nodes with shared CephFS storage can fail during Cloud-Init ISO injection — single-node clusters work, multi-node clusters hit VMProvisionFailed without additional configuration. Again, solvable, but not the "it just scales horizontally" experience CAPH users expect from cloud VMs.
• ClusterClass support depth: CAPMOX exposes the template types for ClusterClass, yet real-node topology (control plane + MachineDeployment + machine templates) is less broadly tested than CAPH's path, and ecosystem projects like Kamaji-assisted control planes document Proxmox separately for a reason.

None of these are disqualifiers. They are the normal texture of a provider that has been in active use at smaller scale than CAPH and that runs against an on-prem API with more operator-owned knobs than a cloud provider's.

The decision: when CAPMOX earns a place in the fleet​

Cluster API's whole point is that infrastructure is pluggable. The question is never "is Proxmox better than Hetzner" in the abstract — it is "does owning a second provider pay for its maintenance cost inside my fleet."

CAPMOX earns its keep when:

• You already own Proxmox hardware that is idle or underutilized. The homelab that migrated from VMware last year, the office Proxmox cluster that runs NAS and CI, or the EU edge site where data must stay on owned hardware in a specific jurisdiction. CAPMOX turns latent capacity into schedulable Kubernetes nodes without buying more cloud.
• Sovereignty or network locality dictates placement. A European public-sector or regulated-industry workload that benefits from "owned Hetzner-adjacent" sovereignty can Clear an additional bar by running on owned Proxmox hardware in an EU jurisdiction — not because Hetzner is non-sovereign, but because the hardware boundary is one hop shorter.
• You want capacity headroom outside a single provider. Hetzner's status page has carried limited-availability notices for specific Cloud server lines through 2026, driven by high demand and DRAM/NAND constraints. A CAPMOX pool cannot burst elastically like cloud VMs, but it is uncorrelated failure domain: when Hetzner says "no capacity in this location," a static Proxmox pool is still there.
• Per-node density favors LXC for lightweight tenants. A PaaS that hosts many small, single-process services (cron jobs, webhook handlers, tiny APIs) can pack more LXC guests per Proxmox host than full VMs — provided each service's resource profile fits LXC's envelope.

CAPMOX does not earn its keep when:

• You have no Proxmox hardware and would buy it just to match Hetzner on price. The 340 percent evaluation number is not a cost recommendation. A €8.74 Netcup dedicated server or a €4.35 Hetzner CX22 may still win on pure per-core cost and API maturity versus buying and operating Proxmox nodes for cloud workloads that have no locality constraint.
• Your team needs hands-off burst scaling this quarter. CAPH plus Cluster Autoscaler on Hetzner Cloud is a more exercised autoscaling path than CAPMOX's equivalent. If autoscaling is the primary scaling mechanism — rather than a fixed pool with overflow — CAPH alone is the simpler starting point.
• Your workload assumes Docker-layer build semantics. This is the OCI-as-LXC point from the next section: if your pipeline expects Docker layer caching, multi-stage builds, or build-time secrets, the Proxmox OCI path is not where that happens.

The fleet that makes sense for most Bex-style PaaS operators is heterogeneous on purpose: CAPH for the elastic cloud pool that handles variable traffic, CAPMOX for the static, owned-hardware pool that handles base load, locality, and cost floor. Cluster API already supports this — multiple infrastructure providers can coexist in a management cluster — the operational work is templating and upgrade testing, not architecture.

OCI-as-LXC as a PaaS build target: parallel track, not replacement​

The most tempting misread of Proxmox 9.1 is that "run OCI images as LXC" means "publish OCI images the same way and pick the runtime later — VM or LXC — from one artifact."

That is half true.

It is true that the artifact format converges: a standard OCI image built with docker build or nix or ko can be consumed by either a Kubernetes pod (via containerd) or a Proxmox LXC via the conversion. That is a genuine ecosystem win — the image registry becomes a universal distribution channel instead of a Kubernetes-only one.

It is not true that the build pipeline converges. A git-push PaaS like Bex today builds from a bex.yml, a Buildpack, or a Dockerfile — it produces an OCI image as output plus the runtime binding (env vars, port, health check, build args). Running that same image as an LXC still needs Proxmox-specific binding: storage pool assignment, unprivileged/privileged mode selection, network bridge attachment, and LXC-specific resource limits. Those are not encoded in the OCI image. They are infrastructure provider configuration that Cluster API, Terraform, or pct create must supply.

Concretely, for a PaaS builder:

• Keep your build pipeline unchanged — Dockerfile or buildpack → OCI image → registry. That image already runs on your CAPH-backed Kubernetes fleet today.
• Add an optional LXC launch path that consumes the same image tag but supplies Proxmox bindings separately. The community pattern is proxmox-lxc-compose-style YAML where image: is an OCI reference and the LXC creation reproduces the image's entrypoint under LXC. That YAML is not a docker-compose.yml — it is Proxmox-specific.
• Do not treat OCI-as-LXC as a Kubernetes replacement for stateful or privileged workloads. Application containers under LXC are a technology preview; production database, queue, or GPU workloads still belong on QEMU VMs or Kubernetes pods where the isolation and observability stack is mature.

The practical implication: budget one template track for the image and one provider track for the launch binding. If you do not want that second track yet, publish the image and run it only on Kubernetes — the option to launch it as LXC later stays open without rewriting the build.

If you are migrating from VMware today​

For teams arriving at Proxmox from VMware, two 2026 quality-of-life improvements remove the sharpest edges:

ESXi Import Wizard. Since Proxmox VE 8.2, the web UI includes a built-in wizard that imports ESXi VMs directly — disks, network, and cloud-init included — without manually copying VMDKs. Test the migration on one non-production VM first, then migrate production with a documented cutover window. Community guides now cover the import path end-to-end, including post-import fine-tuning for Linux and Windows guests.

Terraform provider alignment. If you provision Proxmox declaratively, the bpg/terraform-provider-proxmox path now tracks the new oci-registry-pull API surface. The filed feature request for a proxmox_virtual_environment_oci_image resource signals where the provider is heading: image pull as a declarative resource rather than an imperative pvesm step.

Neither of these changes makes VMware-to-Proxmox "free." Application licensing, vSAN data layout, and VM-specific device passthrough still require per-workload inspection. What they do is make the homelab-to-production path the same tooling — CAPMOX, Terraform, or both — rather than a separate manual migration.

A heterogeneous fleet is the point​

The VMware exodus did not produce a monoculture. It produced a triage: tenants who could pay Broadcom's new floor did, tenants who needed a cloud VM API stayed on Hetzner Cloud, and tenants who owned hardware or needed sovereignty landed on Proxmox. The 340 percent Gartner number captures the decision to evaluate, not the decision to standardize — most evaluators will land on one primary and one secondary, not one replacement.

For a self-hosted PaaS that already draws its fleet boundary on owned hardware, the lesson is not "default to Proxmox" and not "ignore Proxmox." It is that Cluster API lets you stop pretending a fleet has one provider. A management cluster running CAPH for elastic cloud VMs and CAPMOX for owned-hardware pools — with the same git-push API, the same App CRD, and the same TLS and domain routing above it — is a more resilient topology than either pool alone. The cost argument for self-hosting was always about the shape of the bill; the provider-diversity argument is about the shape of the blast radius.

If you are weighing the split, start small: put non-production and preview environments on CAPMOX first, keep production traffic on CAPH, and measure the operational delta (upgrade cadence, autoscaler behavior, bare-metal provisioning time) before expanding. OCI-as-LXC can wait until you have a service whose resource profile clearly fits LXC — the registry will still be there when you are ready.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. The Cluster API fleet underneath is provider-pluggable by design; whether your nodes are Hetzner Cloud VMs, Proxmox QEMU guests, or both, the bex.yml stays the same. Star the repo on GitHub or deploy your first app today.