Spinifex runs AWS ECS workloads on bare metal with no AWS connection required

Spinifex, a project that re-implements Amazon's Elastic Container Service outside of AWS, lets teams run the standard ECS cluster, task definition and service model on their own hardware — including environments with no connection to AWS at all, according to a how-to published on dev.to.

How it works

ECS is the option many teams pick when they want container scheduling without Kubernetes' complexity, but as the dev.to post notes, it is normally welded to AWS: the scheduler is a managed service, capacity means EC2 instances, and the whole system assumes reachability to amazonaws.com. Spinifex reproduces the EC2 launch type instead, which means you bring the compute. A cluster stays a logical grouping, while capacity comes from ordinary instances booted from the spinifex-ecs-node image, each running the Spinifex ECS agent. On boot the agent enrols the node in a cluster, advertises its free CPU and memory, and launches whatever containers the scheduler assigns to it.

There is no Fargate equivalent. Task definitions that declare FARGATE compatibility are accepted but not honoured, so the practical change for Fargate users is that instance counts are managed manually rather than provisioned on demand. Task definition and service configuration otherwise carry over unchanged.

The familiar API surface

Standard aws ecs CLI calls work as expected: create-cluster, register-task-definition, run-task and create-service are all demonstrated in the post. The awsvpc network mode matches AWS behaviour — every task gets its own ENI and private IP inside your subnet — and ALB integration requires IP-type target groups. Services keep a desired count of tasks alive, replace failed ones, and register task IPs with the target group.

Instances need an ecsInstanceRole instance profile, which the Spinifex console's provision-capacity action creates on first use and the ECS Quickstart Terraform workbook sets up automatically unless you opt out.

Credentials, logging and deployments

Task IAM roles work through the same mechanism AWS uses: the agent injects AWS_CONTAINER_CREDENTIALS_RELATIVE_URI into each container and serves short-lived role credentials from 169.254.170.2, letting any AWS SDK authenticate without static keys. An execution role, when configured, is used to authorise ECR image pulls instead of falling back to the instance role.

Logging is where parity ends. Only the -file driver, containerd's default, is honoured; output lands on the container instance and must be read there via containerd or the host journal, with no CloudWatch Logs route. Definitions asking for awslogs or other drivers are still accepted, and a warning naming the container is logged at registration, so the fallback is visible.

Rolling updates via UpdateService respect minimumHealthyPercent and maximumPercent, and the deployment circuit breaker can fail a rollout whose tasks keep failing to start, optionally reverting automatically to the last good task definition revision.

Known gaps

The dev.to post is blunt that ECS v1 in Spinifex is deliberately minimal. Service discovery is absent — no serviceRegistries and no Cloud Map — so services are reached through their load balancer rather than a DNS name. There are no capacity providers or managed scaling: capacity is the static sum of registered instances, with no autoscaling group binding, so you manage the instance count yourself. And a task definition that declares container secrets[] fails registration with InvalidParameterException rather than running without the values it expects, pushing users toward environment variables or fetching secrets at runtime.

Why it matters

ECS's value proposition has always been simplicity, but that simplicity came with the requirement to run inside AWS. Spinifex makes the ECS mental model — task definitions, services, task roles, target groups — portable to owned hardware and air-gapped networks, which matters for regulated environments, disconnected sites and any team that wants ECS ergonomics without AWS lock-in. The missing pieces (manual capacity, no service discovery, no secret injection, host-local logs) mark it as early-stage, but because the task definition format and service configuration are unchanged, existing definitions and tooling largely transfer as-is.