The AWS API has outgrown AWS. Terraform's AWS provider, the AWS CLI, boto3 and the other SDKs are how a generation of engineers describes infrastructure, and plenty of those engineers work for organisations that can't, or won't, put their workloads in an AWS region. A defence contractor can't. A hospital with strict data residency rules might not be allowed to. A company paying a seven-figure egress bill may have decided it no longer wants to.
Those teams still want the tooling. Two open source projects, used together, let them keep it from the first line of code to production without an AWS account anywhere in the chain. Floci handles development and CI. Spinifex handles production on servers you own.
Where the cloud account usually hides
Let's follow a typical AWS project through its life and count the places it touches AWS. Each developer has a sandbox account, or shares one. CI holds a set of keys so integration tests can create real buckets and queues. A staging environment mirrors production, at production prices. Then production itself.
Every one of those is a bill (and one that seems to grow by the day), a set of credentials to protect, and a dependency on a network connection to a region you don't control. Not to mention, we're starting to see cloud capacity run out altogether. Thus, developing and running cloud-native applications outside of the typical cloud settings is becoming increasingly popular. That doesn't mean we have to ditch the tooling.
Floci takes the laptop and CI
Floci is a free, MIT-licensed emulator that answers AWS API calls on
localhost:4566. It needs no account and no auth token. It
starts in about 24 milliseconds, idles at about 13 MiB of memory, and
covers more than 120 AWS services, which makes it cheap enough to start
fresh for every test run.
Floci emulates most services in-process, but it runs real containers where
fidelity matters. Lambda functions run in AWS runtime images. RDS and
ElastiCache sit on real Postgres, MySQL, MariaDB and Valkey. An EC2
RunInstances call starts a container with user data and an
instance metadata endpoint.
There are some useful settings that Floci leaves off by default. Turn on IAM
enforcement and Floci checks each call against the caller's policies, so a
role missing s3:PutObject fails on the developer's laptop
instead of in production. Turn on security group enforcement and Floci
filters traffic between instance containers. Most local development doesn't
need either, but a team heading for a production platform that enforces
both should switch them on in CI.
That replaces the sandbox accounts and the CI keys. Each pull request gets an empty, disposable AWS account that costs nothing and leaks nothing.
Spinifex takes production
Spinifex is an AGPL-3.0 cloud platform that implements the AWS APIs on
standard Linux servers. Where Floci emulates, Spinifex provisions.
RunInstances boots a KVM virtual machine from an AMI. EBS
volumes are replicated block devices served by Viperblock. S3 objects are
erasure-coded across nodes by Predastore. Security groups become stateful
firewall rules in the virtual switch, and IAM evaluates every request. It
runs with no external control plane and can be installed and operated
without an internet connection.
That replaces staging and production. Staging becomes a Spinifex account, or a small cluster, that looks like production because it is the same platform.
The API is the contract
The workflow holds together because both projects implement the same API.
The application calls put_object, Terraform declares an
aws_instance, and neither knows which platform answers. Between
the laptop and the rack, the endpoint and the credentials change. The code
doesn't.
The AWS SDKs already support this. They read AWS_ENDPOINT_URL
from the environment, so a developer points at Floci, a CI job points at
Floci in a fresh container, and the production deploy points at Spinifex.
Terraform does the same through its provider's endpoints block.
Where the two differ, and why that's useful
An emulator and a production platform answer the same calls with different goals:
Service coverage. Floci covers far more of AWS than Spinifex does, because emulating an API is easier than operating the service behind it. Spinifex serves EC2, EBS, VPC, S3, IAM, STS, ELB, EKS, ECS, ECR, RDS and ACM. It doesn't serve Lambda, DynamoDB, SQS or SNS yet, although they are on the roadmap for upcoming releases.
In general, if the intent is for the application to be developed with Floci and then run on Spinifex, check both platforms' supported services to make sure the overlap is sufficient: Floci's services overview and Spinifex's AWS API coverage page.
What "running" means. On Floci, an instance is a container that starts in seconds. On Spinifex, it's a virtual machine with a real disk, real boot time and real I/O performance. Functional tests belong on Floci. Performance and failure testing belong on Spinifex.
State. Floci starts empty unless you ask it to persist. Spinifex keeps everything until you delete it, so Terraform state matters from the first production apply.
Neither difference is a flaw. Floci is fast and disposable because a test loop needs that. Spinifex is durable and strict because production needs that. Each project covers the stage the other was never built for.
The whole path can run offline
Take the internet away and the workflow still runs. Floci asks for no account or token. The container images it starts for Lambda, RDS and other services can come from a private registry instead of public ones, and Spinifex includes an ECR-compatible registry to host them. Spinifex installs without internet access and never calls home.
A developer inside an air-gapped facility can write code against Floci, a CI runner on the same network can test it, and a Spinifex cluster in the next rack can run it. Nothing leaves the building, and nobody had to give up the AWS tooling they already know to make that happen.
Who this is for
- Sovereign and defence teams who need the AWS developer experience inside a disconnected or classified network.
- Regulated industries whose data can't leave infrastructure they control, at any stage, including test.
- Teams leaving AWS on cost who want to keep their Terraform and SDK code instead of rewriting it for a new platform's API.
- Edge deployments that have to keep working when the link to a region drops.
Get started
Floci is at
github.com/floci-io/floci. One docker run gives you a local AWS endpoint, no sign-up
needed. Spinifex is at
github.com/mulgadc/spinifex, with install guides for single-node, clustered and air-gapped deployments
at docs.mulgadc.com. To try the
production half before buying hardware, the
free Spinifex sandbox gives you a live endpoint for 72
hours.
