"EC2-compatible" has become a somewhat diluted term. Local development tools use it to mean "we mock enough of the API that your code won't crash," and platform vendors use it to mean "we have a concept of virtual machines." What it should mean is that the EC2 API behaves identically to AWS, with the same endpoints, request format, response schema, and error codes, but running on hardware you control. That's what Spinifex implements.
What the API surface actually covers
Spinifex covers a broad surface, and the depth goes well beyond basic instance management:
- EC2 covers instance management including create, start, stop, terminate, and describe; AMIs; security groups; and VPC networking.
- EBS provides volumes, snapshots, and attach/detach operations with the same lifecycle semantics as AWS EBS.
- S3 handles buckets, objects, and presigned URLs using the same SDK operations and path conventions as AWS S3.
- VPC covers virtual networking, subnets, route tables, and security group rules so workloads run in isolated network environments without modification.
- IAM enforces roles, policies, and instance profiles using the same role-based access model you use in AWS, applied at the API level.
- EKS manages the Kubernetes control plane and node lifecycle with the same API as AWS EKS, including eksctl compatibility.
- ECR provides a container registry compatible with the standard Docker and containerd pull flows, so image pipelines don't need changes.
- ECS handles container scheduling and task management, making it possible to run ECS-based workloads on your own hardware without rewriting task definitions.
- RDS exposes a database API compatible with standard AWS RDS tooling and connection strings.
- ALB and NLB provide load balancer management with the same API as AWS Elastic Load Balancing, so Terraform modules that provision load balancers work unchanged.
If you've built tooling or automation against any of those AWS APIs, it transfers without modification.
The one change your Terraform needs
Redirecting Terraform from AWS to Spinifex is a single provider override, and everything else stays the same, including your resource definitions, modules, variable files, and state management:
provider "aws" {
endpoints {
ec2 = var.spinifex_endpoint
iam = var.spinifex_endpoint
sts = var.spinifex_endpoint
eks = var.spinifex_endpoint
s3 = var.spinifex_endpoint
ecr = var.spinifex_endpoint
acm = var.spinifex_endpoint
}
}Engineers who know Terraform for AWS already know how to operate a Spinifex deployment. The only new knowledge required is the endpoint address and the initial installation.
How this differs from local dev mocks
Tools like LocalStack are genuinely valuable for local development, but they're not designed for production workloads and make no guarantees about behavioural parity at the margins, don't perform at scale, and are architected around the assumption that the real workload will eventually run in AWS. The mock is a convenience layer, not a production target.
Spinifex is the opposite use case. It's designed for environments where AWS isn't the target and where the hardware you're running on IS the production environment. That means actual virtual machine management on real bare metal, actual block storage with real persistence, and actual IAM enforcement across real network boundaries. The API compatibility is a consequence of running the same surface, not an approximation of it.
When bare metal is the right call
There are three common reasons to run EC2-compatible compute on your own hardware:
Cost at scale. Cloud egress and compute costs compound, and at sufficient scale, particularly for steady-state workloads without large demand spikes, owning the hardware is cheaper, sometimes substantially so. The break-even point is lower than most engineering teams expect.
Data sovereignty. Regulatory requirements, contractual obligations, or operational security policies may prohibit data leaving infrastructure under your direct control. An EC2-compatible layer means those constraints don't require abandoning your cloud-native toolchain and rebuilding everything from scratch.
Disconnected environments. Tactical edge deployments, remote industrial sites, and secure facilities often have limited or no internet connectivity. Running the same EC2 API surface locally means the deployment and operational model stays consistent regardless of network conditions.
Get started
Reference architectures, including a full EKS GPU cluster deployment on a Supermicro X14, are at docs.mulgadc.com. The source is on GitHub, written in Go and MIT-licensed. Or sign up for our free sandbox to explore the API before deploying on your own hardware.
