If you're evaluating alternatives to VMware, you'll find no shortage of content telling you which hypervisor to pick or how the licensing compares. What's harder to find is an honest account of what you're actually signing up for once the new platform is running.
This post covers the infrastructure options realistically available today, how Giant Swarm's platform sits across all of them using a shared technical foundation, and what the migration from VMware actually looks like in practice.
Since the Broadcom acquisition, many VMware customers have faced significant and often unpredictable price increases. The three alternatives most infrastructure teams are actually evaluating are Nutanix, Proxmox, and bare metal Kubernetes. They are not equivalent choices, and the right one depends heavily on your workload mix and operational model.
Nutanix is the closest like-for-like replacement. It is proprietary, still licensed, and still comes with vendor lock-in, but licensing costs are generally lower than post-Broadcom VMware. If your team needs a supported vendor and your procurement process requires one, it is the path of least resistance.
Proxmox is an open source hypervisor, free to use, with an optional paid enterprise support subscription. Like Nutanix, it gives you a hypervisor layer that lets you carve up physical servers into VMs and provision Kubernetes nodes from those. The key difference is cost and licensing: Proxmox is fully open source with no mandatory licence fee. If your workloads are heterogeneous and you still have non-containerised applications that need VMs alongside containers, keeping a hypervisor layer makes practical sense — and Proxmox is the cost-effective way to do it.
Bare metal Kubernetes removes the hypervisor entirely. One physical server becomes one Kubernetes node. This eliminates hypervisor overhead and licensing cost entirely, but it trades flexibility for simplicity: every workload needs to be containerised, cluster topology tends to be more fixed, and adding new nodes means adding physical hardware. It is the right choice when most of your workloads are already cloud native and you want to run as close to the metal as possible.
Here's how the options compare across the dimensions that matter most:
|
Nutanix |
Proxmox |
Bare Metal |
|
|
Cost vs. VMware |
Lower, but still licensed and proprietary |
Fully open source, free (optional enterprise support) |
Fully open source and free; Giant Swarm fee slightly higher due to setup effort on bare metal |
|
Who manages it |
Customer manages fully |
Shared, or optionally managed by Giant Swarm |
Mostly Giant Swarm (customer handles physical racks and servers; we manage everything above) |
|
Best suited for |
Teams wanting a supported vendor; familiar procurement patterns |
Teams with heterogeneous workloads that still need VMs alongside containers; open source preference with optional commercial support |
Teams with mostly containerized workloads; no hypervisor overhead; steady topology with larger nodes |
|
KubeVirt |
Giant Swarm can run KubeVirt on bare metal for workloads that still need VMs and are not yet containerized |
The reason Giant Swarm can support Nutanix, Proxmox, and bare metal through a single platform is Cluster API (CAPI). CAPI is a Kubernetes sub-project that provides a declarative, infrastructure-agnostic API for provisioning and managing Kubernetes clusters. Each infrastructure target has its own CAPI provider: CAPX for Nutanix, CAPMOX for Proxmox, and Metal3 for bare metal.
What this means in practice is that the Giant Swarm platform itself does not change depending on which infrastructure you run it on. The management cluster, the GitOps reconciliation layer via FluxCD, the upgrade lifecycle, the observability stack, the security bundle — these are consistent across all three. The infrastructure provider is a pluggable layer underneath.
On Proxmox, workload cluster nodes are VMs provisioned from versioned Flatcar Container Linux templates via CAPMOX. Proxmox has no native load balancer, so the platform ships with kube-vip — a layer-2 load balancer that handles control plane endpoint availability using ARP or BGP.
On bare metal, the model is the same minus the hypervisor. Physical servers are registered as nodes directly, and Giant Swarm manages Kubernetes on top of them. No virtualisation layer, no additional licence.
On Nutanix, the CAPX provider handles cluster provisioning against the Nutanix AHV hypervisor, with the same management model and release cadence as the other targets.
Each release bundles a tested, compatible set of components: Kubernetes, Flatcar Linux, Containerd, Cilium for networking and security, the observability bundle, and the security bundle. These are versioned and tested together before they reach your clusters — which is what makes upgrades manageable rather than an ongoing integration problem.
The most common concern we hear from teams evaluating a VMware exit is the migration itself. The fear is a hard cutover: everything has to move at once, something breaks, and the team spends weeks firefighting.
Because Giant Swarm plugs into multiple infrastructure providers through the same Cluster API foundation, the migration does not have to work that way.
The typical path looks like this:
This approach means the migration is a series of small, reversible steps rather than a single high-risk event. At no point is the team forced to cut over everything at once.
One objection we hear frequently from teams considering bare metal is that not everything is containerised yet. Some legacy applications still need to run in virtual machines. Going to bare metal Kubernetes seems to close that door.
KubeVirt solves this. It is a Kubernetes extension that allows virtual machines to run as native Kubernetes workloads, managed through the same kubectl interface and GitOps workflows as containers. Giant Swarm can deploy and manage KubeVirt on bare metal clusters, which means teams choosing bare metal do not have to containerise everything before they can migrate.
In practice, teams use KubeVirt as a transitional layer: run the legacy VM-based workloads in KubeVirt while containerisation work happens in parallel. Once a workload is containerised, it moves to a standard deployment and the VM is retired. The infrastructure does not have to wait for the application team.
Before anything else, it helps to be precise about layers, because this is where expectations drift and migrations get complicated.
Proxmox, bare metal, or Nutanix is your infrastructure layer. You own and operate it, or you choose a managed service provider for it. Giant Swarm sits above that: we deploy and manage Kubernetes on top of your infrastructure. We are not a Proxmox managed service and we do not handle VM migration. What we do is take everything from the Kubernetes layer upward off your team's plate.
Things that remain with your team: the infrastructure layer underneath, application-level incidents in your own workloads, network topology decisions for your environment, physical capacity planning on bare metal, and any compliance or security controls that sit outside the platform layer.
Things that are ours: the Kubernetes platform, the cluster lifecycle, the upgrade cadence, the observability stack, the security bundle, and 24/7 incident response for anything in the platform layer. When something breaks, an alert fires and pages our on-call team. A P1 incident triggers a two-person response with updates to the customer every 30 minutes until resolution, followed by a written postmortem.
In practice the boundary is clear but the collaboration is close. We share a Slack channel with your team, join planning meetings where the platform is relevant, and are on incident bridges when something goes wrong. When an issue touches the platform layer, we are the ones investigating — not a ticket queue.
Running Kubernetes on Proxmox or bare metal without a managed platform is a real option. The components are open source, the documentation exists, and plenty of teams have done it. What they have also found is that the ongoing operational work — upgrades, scaling, incident response, security patching, certificate rotation, observability tuning — is a full-time job for more than one person.
The question for most teams is not whether they can do this themselves. It is whether it is the best use of the people they have.
Reach out if you want to talk through the specifics — which infrastructure path makes sense, what the layer boundary looks like for your setup, and what a realistic first 90 days looks like — we offer free assessment calls to do exactly that.