Free Spinifex sandbox. Create a sandbox Your Spinifex account is live. Access your console
Layer_1
Practical guide

A self-hosted AWS-compatible cloud on your hardware.

Spinifex gives your infrastructure an AWS-compatible service surface without depending 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.

Keep evaluating

Related Spinifex guides

Test the fit

Point familiar AWS tooling at Spinifex.

Use a sandbox to test the APIs your workload actually depends on.

Create a sandbox account