A self-hosted AWS-compatible cloud on your hardware.
Spinifex is an open-source cloud that serves AWS-compatible EC2, S3, VPC, IAM, EKS and RDS APIs from your own Linux servers, with no dependency on an AWS region. Run it in your data centre, on an edge appliance, or in a disconnected site.
What “self-hosted AWS” means here
AWS itself is not software you can install. A self-hosted AWS environment is therefore an infrastructure platform that implements compatible APIs for the services a workload uses. Spinifex provides those interfaces locally for compute, block storage, object storage, networking, and identity.
Your existing AWS-aware client talks to the Spinifex endpoint. The control plane schedules work onto your Linux hosts and stores data on the infrastructure you operate. No external control plane or cloud reach-back is required for the local service surface.
What stays familiar and what becomes yours
Stays familiar
AWS CLI commands, SDK request shapes, SigV4 credentials, Terraform resources, and EC2/EBS/S3/VPC/IAM concepts.
You operate
Hosts, disks, networking, capacity planning, upgrades, failure domains, monitoring, and the physical security of the deployment.
You control
Data location, jurisdiction, encryption keys, network boundaries, hardware selection, and when the platform connects to another network.
Three ways to start
Existing Linux host
Use the source installation path to evaluate Spinifex on a machine you already control.
Bootable installation
Install from the released image onto bare metal for a dedicated single-node or clustered environment.
Hosted sandbox
Test the AWS-compatible APIs before selecting hardware or designing the production topology.
The bare-metal install guide covers the bootable path, while the Spinifex repository contains source, releases, and current installation instructions.
Plan the deployment around the workload
Begin with a representative application, not an abstract goal to replace every AWS service. Capture the API calls it makes, its compute and storage demand, its network boundaries, and its recovery objectives. Test those calls in a sandbox, then size the hosts and failure domains for that workload.
- Use a single node for evaluation or compact sites where that failure model is acceptable.
- Use a multi-node cluster when the workload needs distributed capacity and service continuity.
- Place a deployment at the edge when latency or disconnection makes a remote region unsuitable.
- Use a partner Neocloud when you want compatible APIs without operating the hardware yourself.
Review the Spinifex product overview and deployment shapes before moving from an API compatibility test to production design.
Frequently asked questions
Can you self-host AWS?
Not AWS itself, which is software only Amazon runs. You can self-host a platform that implements the same APIs. Spinifex is open source (AGPL-3.0) and serves AWS-compatible EC2, EBS, S3, VPC, IAM, EKS, ECS and RDS endpoints from your own Linux servers, so the AWS CLI, SDKs and Terraform work by changing the endpoint.
What hardware does a self-hosted AWS-compatible cloud need?
Spinifex runs on standard x86 or ARM servers with no proprietary hardware. A single node is enough to evaluate it, and a multi-node cluster adds distributed capacity and service continuity for production.
How do I point the AWS CLI at a self-hosted cloud?
Set the endpoint URL for each service, either per command with --endpoint-url or in your AWS config file, and use access keys issued by Spinifex IAM. SDKs and the Terraform AWS provider take the same endpoint overrides.
Can a self-hosted AWS environment run air-gapped?
Yes. Spinifex installs from a bootable ISO, and every service runs locally with no dependency on AWS or on Mulga, which makes it suitable for disconnected, sovereign and edge sites.
How is self-hosting Spinifex different from AWS Outposts?
Outposts installs AWS-owned hardware in your facility and stays managed from, and connected to, an AWS region. With Spinifex you buy and own the hardware, operate the platform yourself, and keep running when the site is disconnected.
Point familiar AWS tooling at Spinifex.
Use a sandbox to test the APIs your workload actually depends on.