Proxmox VE and Spinifex are both open source platforms for running virtual machines on hardware you own, and both are licensed under AGPLv3. That's roughly where the similarity ends. Proxmox is a hypervisor management platform with a web interface, a REST API, and deep integrations for storage and clustering. Spinifex is an AWS-compatible cloud platform whose entire interface is the AWS API surface, covering EC2, S3, IAM, EKS, and more of the common AWS services. The question of which to use comes down to a simpler underlying question: how does your team want to interact with infrastructure?
What Proxmox actually is
Proxmox VE is a complete virtualisation management platform that combines KVM for full VM workloads and LXC containers for lightweight Linux deployments. It ships with a polished web interface that handles VM creation, live migration, snapshot management, and cluster administration without requiring command-line work. The clustering engine supports up to 32 nodes with high availability, live migration, and a built-in dynamic load balancer added in version 9.2. Storage is handled through native Ceph integration and ZFS support, both of which are configured and managed directly through the Proxmox UI or its REST API.
As of early 2026, Proxmox reports more than 800,000 hosts running the platform worldwide, and major providers including OVHcloud and Hetzner run Proxmox in production at scale. The platform has grown steadily since 2023, driven by organisations looking to move off VMware following Broadcom's acquisition and the pricing changes that followed.
The Proxmox REST API is comprehensive and well-documented, covering the full lifecycle of VMs, storage, networking, and cluster management. What it doesn't provide is any compatibility with the AWS API surface. If you run aws ec2 describe-instances against a Proxmox host, it won't work. Proxmox speaks Proxmox, not EC2. Your AWS tooling, Terraform AWS provider configs, and SDK integrations will need to be replaced or maintained separately.
What Spinifex actually is
Spinifex is an open source AWS-compatible cloud platform that implements the same API surface as AWS, running on standard Linux bare metal hardware. When you call aws ec2 run-instances against a Spinifex node, it boots a real virtual machine using QEMU under the hood. When you call aws s3 cp, it stores real objects in Predastore, the platform's built-in S3-compatible object storage. The platform includes a web UI, but the primary management surface is the AWS API: the same Terraform configs, CLI scripts, and SDK integrations your team already uses for AWS work against Spinifex without modification.
The platform installs from a release tarball via a setup script, and from that point the AWS CLI, Terraform with the AWS provider, eksctl, boto3, and any other AWS tooling work against your own hardware the same way they work against AWS. Spinifex is written in Go, AGPL-3.0 licensed, and runs fully offline with no external control plane and no phone-home dependency.
The question that determines the right answer
Proxmox and Spinifex solve different problems for different users. The right choice depends on how your team operates infrastructure today.
If your team manages infrastructure through Proxmox's own UI and API, or through tools built specifically for Proxmox such as Terraform's Proxmox provider, then Proxmox is a mature and well-supported platform that handles the VM lifecycle well. It has a large community, extensive documentation, and a track record in production at scale. For organisations migrating from VMware, Proxmox is often the most direct path because it replaces the hypervisor layer with something that behaves similarly, just without the licensing cost.
If your team manages infrastructure through the AWS CLI, through Terraform with the AWS provider, through eksctl, or through any AWS SDK, then Spinifex lets you keep doing that on hardware you own. The Terraform provider override that redirects from AWS to Spinifex is a single block change, and everything downstream including your resource definitions, modules, and variable files stays the same. Engineers who know AWS already know how to operate a Spinifex deployment.
Where the choice gets more nuanced
Some situations require more thought than the straightforward toolchain match suggests.
For organisations that have existing AWS automation they want to preserve and are also running a Proxmox cluster for general VM infrastructure, these tools don't directly overlap. Proxmox manages the infrastructure it controls through its own API. Spinifex manages the infrastructure it controls through the AWS API. They're not competing for the same VMs unless you're considering which platform to run a new workload on.
For teams evaluating on-prem options without an existing toolchain in either direction, the choice often comes down to which mental model fits better. Proxmox's UI has been refined over more than a decade specifically around VM lifecycle management and is the primary way most teams interact with it day-to-day. Spinifex also has a web UI, but its tooling is built around the AWS API first, so teams coming from an AWS background will find the CLI and Terraform workflow more natural.
For air-gapped environments, both platforms can run without internet connectivity. Spinifex's offline installer is specifically designed for fully disconnected deployment, with documented procedures for transferring the release tarball and dependencies via USB media and suppressing the install telemetry beacon with --no-telemetry. Proxmox also runs offline, though the specifics of air-gapped package management differ.
Licensing and support
Both platforms use AGPLv3. Proxmox offers optional paid subscriptions that provide access to enterprise-stable package repositories and direct support from Proxmox Server Solutions GmbH, without unlocking any additional software features. The community repository is available without a subscription. Spinifex is community-supported through GitHub.
Getting started
Proxmox VE documentation and downloads are at proxmox.com. Spinifex documentation is at docs.mulgadc.com and the source is on GitHub. If you're evaluating Spinifex and want to test the AWS API surface before deploying on your own hardware, the free sandbox exposes the same endpoint and credential model as a self-hosted installation.
