The decision to move workloads off public cloud onto hardware you control usually comes with a secondary question that gets answered too late: what happens to the tooling? Terraform configs, CLI automation, IAM role structures, Kubernetes clusters provisioned with eksctl, all of that was written against the AWS API, and the answer to "does it work on our private cloud?" depends almost entirely on which private cloud platform you choose. OpenStack and Spinifex give different answers to that question, so let's dive into what they both are and where you'd pick either one.
What OpenStack actually is
OpenStack is the incumbent open source private cloud platform, governed by the OpenInfra Foundation and running at serious scale. According to the OpenInfra Foundation, OpenStack deployments now exceed 55 million cores in production worldwide, with organisations including Walmart, Workday, and CERN among the large-scale operators. Telecoms have leaned heavily on it for 5G and Open RAN backbone infrastructure through the StarlingX project. It is a mature platform with over fifteen years of production hardening behind it.
The core services cover the same ground as any cloud platform: Nova for compute, Neutron for networking, Cinder for block storage, Swift for object storage, Keystone for identity and authentication, Glance for image management, and Heat for orchestration. Each is a full project in its own right, with its own API, documentation, and upgrade lifecycle.
The operational reality
Deploying OpenStack for production use is not a weekend project. The most accessible deployment path today is Kolla-Ansible, which containerises OpenStack services and uses Ansible to orchestrate the install, and it has simplified what used to be an extremely manual process. The official documentation acknowledges that Kolla "permits operators with little experience to deploy OpenStack quickly," which is true in the sense that a motivated team can get a cluster running, but running it at production quality and knowing how to troubleshoot failures across distributed containerised services still requires operational expertise. OpenStack networking in particular, built on Neutron with OVN or OVS, has a learning curve that most teams underestimate.
For organisations with a dedicated cloud operations team, this is a reasonable trade. Engineering teams whose core expertise is software development rather than infrastructure operations will carry the operational overhead with less to absorb it.
The AWS API question
The challenge for teams moving from AWS tooling is that OpenStack has its own API surface. Nova is not EC2, Cinder is not EBS, and Keystone is not IAM. Terraform resources written for AWS use the aws provider and EC2/EBS/S3 resource types, and those don't translate to OpenStack without a rewrite using the OpenStack provider.
There was an OpenStack project called ec2-api that provided an AWS EC2 compatibility wrapper for OpenStack, but that project is retired and no longer maintained. An organisation moving workloads from AWS to OpenStack is taking on a migration project at the Terraform and automation layer, not just at the infrastructure layer. Every aws_instance, aws_security_group, and aws_eks_cluster resource in your configurations needs to be rewritten for the OpenStack equivalents.
Your existing AWS tooling transfers to Spinifex without modification. It does not transfer to OpenStack without rewriting it.
What Spinifex does differently
Spinifex takes the opposite approach to the API question. Rather than building a new cloud platform with its own API surface, it implements the AWS API on hardware you own, covering EC2, S3, IAM, EKS, and the rest of the common AWS service surface. The endpoint changes; the API does not. A Terraform config that targets AWS today can target a Spinifex node with a single provider block override, and the resource definitions, modules, variable files, and state management stay exactly as they are.
The operational profile is also different. Spinifex runs as a single platform on standard Linux hardware, coordinated by NATS and managed by systemd, with no separate etcd cluster and no external control plane components. It also installs and runs in fully air-gapped environments with no internet connectivity, which is a requirement OpenStack can satisfy in principle but which requires additional planning and configuration to achieve.
Spinifex is AGPL-3.0 licensed and written in Go, with the source at GitHub.
When OpenStack is the right choice
OpenStack is the right choice when the scale and multi-tenancy requirements of the deployment justify its operational complexity. Service providers running public or community cloud infrastructure, telecoms deploying 5G core, and large enterprises with dedicated cloud operations teams are the natural users of OpenStack, and it serves them well. If you need a platform that hundreds of teams can share with strong tenant isolation and a mature ecosystem of plugins, integrations, and management tooling built up over fifteen years, OpenStack is where you start looking.
When Spinifex is the right choice
Spinifex is the right choice when your team has existing AWS tooling and the requirement is to run that tooling on hardware you own, without a migration project at the automation layer. Disconnected environments, data sovereignty requirements, and edge deployments are where the AWS API compatibility matters most. Teams that can't justify a dedicated cloud ops function benefit from Spinifex's simpler operational profile.
Before choosing between them, ask what your team needs to operate the platform and whether you have it. For teams whose existing capability is AWS, that question often determines the outcome before the feature list does.
Get started
Platform documentation for Spinifex, including the air-gapped installation guide and Terraform workbooks for common infrastructure patterns, is at docs.mulgadc.com. The source is on GitHub. OpenStack documentation and deployment guides are at docs.openstack.org, and the OpenInfra Foundation can be found at openinfra.org. Or sign up for the Spinifex free sandbox to explore the AWS-compatible API surface before deploying on your own hardware.
Top comments (0)