Spinifex reuses AWS CLI tooling on air-gapped hardware via a single endpoint override

A post on dev.to introduces Spinifex, software that implements AWS service APIs on hardware you own so that the AWS CLI and the ecosystem around it keep working without a connection to Amazon's cloud. The central claim is that commands engineers already rely on — aws ec2 describe-instances, aws s3 cp, eksctl — remain unchanged, and only the endpoint they target moves.

The assumption that breaks off the cloud

According to the post, the AWS CLI, every AWS SDK and any Terraform provider built on them assume connectivity to AWS's public endpoints. In air-gapped settings — secure facilities, disconnected field operations, industrial sites without public internet — that assumption fails. What disappears is not just the API but everything layered on top of it: Terraform plans, eksctl-managed clusters, custom automation scripts and CloudWatch integrations.

The usual answer is a parallel toolchain for on-premises work, with separate automation, monitoring and documentation. The post argues this is expensive, drifts away from the cloud baseline over time, and forces engineers to context-switch between two operational models.

One endpoint change instead of a new toolchain

Spinifex exposes an AWS-compatible API surface — the post names EC2, EBS, S3, VPC, IAM, EKS, ECR, ECS and RDS — at a local endpoint running on your own hardware. Because the API is identical, the post says, no tooling needs to change: the AWS CLI cannot tell whether it is talking to AWS or Spinifex. Redirecting it is a profile entry that sets endpoint_url to the node's address, and a setup command, spx admin init, writes that profile automatically and names it after the node.

For one-off operations there is the --endpoint-url flag, which overrides the target for a single command without touching configuration. The post says most teams end up using both: a persistent profile for automation and CI, and the flag for exploratory work. The only modification existing scripts need is the endpoint override.

Real services, not a mock

The post is emphatic that this is not a partial emulation. Behind the endpoint, Spinifex runs actual EC2 compute on your hardware, EBS volumes with genuine persistence, S3-compatible object storage and functioning EKS clusters. What changes is where the compute runs, not how you interact with it. The endpoint can sit on a local network, a VPN, a Tailnet or a fully air-gapped LAN with no external routes; as long as the CLI can reach it, the setup works.

Where the fit is

The post lists four scenarios: edge deployments that operate without a reliable uplink but still need cloud-grade tooling; classified or restricted facilities that prohibit egress to commercial cloud providers; data sovereignty obligations requiring compute to stay on infrastructure under direct control; and steady-state workloads where owned hardware is more economical than cloud at scale.

One caveat worth noting: the piece reads as vendor documentation, pointing readers to its own air-gapped installation guide and a free sandbox, so the capability claims are the vendor's and no independent evaluation is included.

Why it matters

The hardest part of moving workloads out of the cloud, or running them alongside it, is often the operational tooling rather than the compute itself. Teams that have invested years in Terraform modules, CLI automation and IAM policy design usually have to write much of that off when a workload must run disconnected. An AWS-compatible local endpoint reframes the problem as configuration — change where the commands point, keep everything else. If the compatibility holds across the breadth of services listed, it also removes the drift and duplicate maintenance that come from running two toolchains in parallel. The open question the post does not answer is how complete and durable that emulation is under production load, which any evaluating team would want to test before committing.