The AWS CLI is on almost every developer's machine. Once you've built habits around commands like aws ec2 describe-instances, aws s3 cp, and eksctl create cluster, the idea of switching to different tooling for on-prem or edge deployments is genuinely painful. Most engineers assume there's no alternative, but with Spinifex there is. The CLI keeps working, and you just change the endpoint.
Why the CLI breaks in disconnected environments
The AWS CLI, every AWS SDK, and any Terraform provider wrapping them assume connectivity to amazonaws.com. In air-gapped environments such as secure facilities, disconnected field operations, and industrial sites with no public internet, that assumption is fatal. You lose not just the API but the entire ecosystem built on top of it, including Terraform plans, eksctl clusters, custom automation scripts, and CloudWatch integrations.
The typical workaround is maintaining a completely separate toolchain for on-prem: separate automation, separate monitoring, separate knowledge base. It's costly, it diverges from the cloud baseline over time, and it means engineers need to context-switch between two completely different operational models.
How Spinifex makes it work
Spinifex implements the same API surface as AWS, covering EC2, EBS, S3, VPC, IAM, EKS, ECR, ECS, RDS, and more, at a local endpoint running on your hardware. Because the API is identical, none of the tooling needs to change. The AWS CLI doesn't know or care whether it's talking to AWS or Spinifex, and redirecting it is a single profile entry:
[profile spinifex-node1]
aws_access_key_id = your-key
aws_secret_access_key = your-secret
endpoint_url = https://<node-ip>:9999
region = us-east-1
In practice, spx admin init writes this profile automatically, naming it spinifex-<nodename> and pointing it at the node's IP. From that point, every aws command run with that profile goes to your local Spinifex instance with no internet required and no changes to existing scripts.
Or per-command with --endpoint-url
For one-off operations or testing, the --endpoint-url flag overrides the endpoint for a single command without touching your profile config:
aws --endpoint-url https://<node-ip>:9999 ec2 describe-instances
aws --endpoint-url https://<node-ip>:9999 eks list-clusters
aws s3 ls s3://my-bucket --endpoint-url https://<node-ip>:8443
Both approaches work identically. The choice is whether you want Spinifex as a persistent named profile or an occasional per-command override, and most teams set up both, using the profile for automation and CI and the flag for exploratory work.
The only change your existing scripts need is a single endpoint override.
What you actually get
This isn't a mock or a subset of the API. Spinifex runs real EC2 compute on your hardware, real EBS volumes with genuine persistence guarantees, real S3-compatible object storage, and real EKS clusters, all behind an endpoint that the AWS CLI treats as AWS. What changes is where the compute runs, not how you interact with it.
The implication for air-gapped deployments is significant. Workloads that previously required a completely different deployment model, because they couldn't connect to AWS, can now be built and operated with the same Terraform configs, the same CLI automation, and the same IAM policies. The Spinifex endpoint can be on a local network, a VPN, a Tailnet, or a completely air-gapped LAN with no external routes, and as long as the CLI can reach the endpoint, it works.
Typical use cases
- Disconnected field deployments are a natural fit, where edge infrastructure operates without a reliable uplink but still needs the same operational tooling as the cloud environment.
- Secure facilities such as classified or restricted environments often prohibit network egress to commercial cloud providers entirely, making a local API endpoint the only viable approach.
- Data sovereignty requirements, including regulatory or contractual obligations that data remain on infrastructure under your direct control, are satisfied when the compute never reaches the public internet.
- Cost control becomes straightforward for steady-state workloads where compute costs at scale make owned hardware more economical than cloud.
Try it yourself
The full setup walkthrough, including TLS configuration for production air-gapped deployments, is in our air-gapped installation guide. Or sign up for our free sandbox to explore the API surface before deploying on your own hardware.
