On March 23, 2026, LocalStack archived its public GitHub repository and moved all images behind authentication. If you ran docker pull localstack/localstack in CI without a token, your pipeline broke.
The immediate question — "how do I get my CI running again?" — has an answer. The longer question — "what replaces LocalStack for the next two years?" — is more interesting and less covered.
This is the longer answer.
What You're Actually Choosing Between
Three tools have real traction as LocalStack replacements in Python stacks:
| Tool | What it is | Auth required | Docker required |
|---|---|---|---|
| moto | Python library — mocks AWS in-process | No | No |
| Floci | Go service — runs as a Docker container | No | Yes |
| LocalStack Community | Full AWS emulator — runs as a Docker container | Yes (free non-commercial token) | Yes |
These aren't interchangeable. They operate at different layers and suit different testing scenarios.
moto: The Python-First Choice
Moto patches boto3 calls directly inside your test process. No Docker, no network round-trips, no external service to keep running. Tests are fast — AWS calls go through an in-memory mock, not over a socket.
import boto3
from moto import mock_aws
@mock_aws
def test_upload_and_read():
s3 = boto3.client("s3", region_name="us-east-1")
s3.create_bucket(Bucket="test-bucket")
s3.put_object(Bucket="test-bucket", Key="config.json", Body=b'{"env": "test"}')
response = s3.get_object(Bucket="test-bucket", Key="config.json")
assert response["Body"].read() == b'{"env": "test"}'
No setup. No teardown. No auth token. The @mock_aws decorator intercepts every boto3 call made inside the test function.
Moto strengths:
- Fastest possible tests — no network, no container startup
- Apache 2.0, pure open source, no account needed
- Deep service coverage: S3, DynamoDB, SQS, SNS, Lambda, IAM, EC2, Secrets Manager, and 50+ more
- Maintained by a large community with years of production use
Moto limits:
- In-process only — can't test code that calls AWS from a different process, container, or service
- Doesn't test the HTTP layer (if you're validating Terraform or CDK infrastructure, moto can't help)
- Lambda execution is limited — no actual runtime environment
Best for: Unit tests, integration tests where your Python code is the only caller of AWS.
Floci: The Drop-In Docker Replacement
Floci launched on March 22, 2026 — two days before the LocalStack archival. It runs as a Docker container on port 4566, the same port LocalStack used, with the same endpoint conventions. No auth token.
# GitHub Actions — full replacement for localstack/localstack
- name: Start Floci
run: docker run -d -p 4566:4566 --name floci hectorvent/floci:latest
Your existing AWS SDK calls, Terraform configs, and CDK tests don't need changes — just swap the container.
Floci strengths:
- Zero auth — works in CI without tokens or accounts
- Port 4566 compatibility — typically a drop-in swap for LocalStack Community Edition
- Active development: 1,600+ GitHub stars in 48 hours, 51 forks, multiple external contributors
- Confirmed service coverage (v1.0.5, README): S3, SQS, DynamoDB (with Streams), RDS (PostgreSQL/MySQL + IAM auth), ElastiCache (Redis + IAM auth), API Gateway v2/HTTP API, Cognito, IAM, STS, Kinesis, KMS — plus 20+ services total per project docs
Floci limits:
- Very new — launched 48 hours before this article was written
- Smaller service catalog than LocalStack's full offering
- AI-assisted codebase — validate service behavior against real AWS before relying on it for production CI
- No
testcontainers-flocipackage yet (useDockerContainerdirectly — see snippet below)
Best for: Integration tests, CDK/Terraform testing, multi-service workflows that need a real HTTP endpoint.
Using Floci with testcontainers-python:
import boto3
import pytest
from testcontainers.core.container import DockerContainer
from testcontainers.core.waiting_utils import wait_for_logs
@pytest.fixture(scope="session")
def floci():
container = DockerContainer("hectorvent/floci:latest")
container.with_bind_ports(4566, 4566)
with container:
wait_for_logs(container, "Ready", timeout=30)
yield container
def test_s3_workflow(floci):
s3 = boto3.client(
"s3",
endpoint_url="http://localhost:4566",
region_name="us-east-1",
aws_access_key_id="test",
aws_secret_access_key="test",
)
s3.create_bucket(Bucket="integration-bucket")
s3.put_object(Bucket="integration-bucket", Key="data.json", Body=b'{"ok": true}')
result = s3.get_object(Bucket="integration-bucket", Key="data.json")
assert result["Body"].read() == b'{"ok": true}'
LocalStack: Still an Option
LocalStack Community Edition is still available under Apache 2.0 — the code was not relicensed. What changed is distribution: the Docker images now require authentication, and CI pipelines need a token.
Getting a free Hobby token takes about 10 minutes at app.localstack.cloud. The Hobby tier is free for non-commercial use and includes unlimited CI runs under the new token model (as of the 2026.03.0 release).
# GitHub Actions — with token
- name: Start LocalStack
uses: LocalStack/setup-localstack@v2
with:
image-tag: latest
env:
LOCALSTACK_AUTH_TOKEN: ${{ secrets.LOCALSTACK_AUTH_TOKEN }}
Still a good choice if:
- You need services outside Floci's current coverage
- Your team already has LocalStack Pro features in the workflow
- You want maximum service parity with real AWS for pre-production testing
Not the right choice if:
- You're an open source project that can't use non-commercial licenses
- Your CI is ephemeral and you don't want to manage token secrets
The Decision
Is your code the only process calling AWS?
├── Yes → Use moto. Fastest, zero auth, zero Docker.
└── No (Terraform, CDK, multi-service, or multi-container tests)
│
├── Do you need services beyond Floci's confirmed coverage?
│ (Check https://github.com/hectorvent/floci — 20+ services, growing fast)
│ └── Yes → Use LocalStack with a Hobby token.
│
└── Floci covers your services?
└── Yes → Use Floci. Zero auth, drop-in swap.
Most Python-focused projects land in the moto column. If you're testing application code that calls boto3, moto handles it with no infrastructure overhead.
Floci takes the integration test slot — the scenarios where you need a real Docker service running on port 4566 and don't want to manage an auth token.
LocalStack stays relevant for advanced scenarios: full service catalog, CDK bootstrap testing, LocalStack Pro features.
Migrating from LocalStack to moto (5 minutes)
Before (LocalStack):
# conftest.py
import boto3
import pytest
@pytest.fixture
def s3_client():
return boto3.client(
"s3",
endpoint_url="http://localhost:4566",
region_name="us-east-1",
aws_access_key_id="test",
aws_secret_access_key="test",
)
After (moto):
# conftest.py
import boto3
import pytest
from moto import mock_aws
@pytest.fixture
def s3_client():
with mock_aws():
yield boto3.client("s3", region_name="us-east-1")
The only change is the fixture. Your test functions don't change.
Migrating from LocalStack to Floci (2 minutes)
If you're using Docker Compose:
# Before
localstack:
image: localstack/localstack
environment:
- LOCALSTACK_AUTH_TOKEN=${LOCALSTACK_AUTH_TOKEN}
ports:
- "4566:4566"
# After
floci:
image: hectorvent/floci:latest
ports:
- "4566:4566"
Remove the auth token, swap the image. Your endpoint URLs (http://localhost:4566), your AWS SDK config, and your existing test code all stay the same.
The Bigger Picture
LocalStack's pivot follows the Elastic/MinIO/Redis pattern exactly: community-built project, Apache-licensed code, closed distribution. Organized opposition is unlikely. Individual migration is the response.
The migration window is open now. moto is the safe, fast choice for Python unit tests. Floci is the zero-auth alternative for integration scenarios. LocalStack with a Hobby token is still viable if you need the full catalog.
Pick the right tool for your test layer. You probably need moto and one of the Docker options — they're not competing, they solve different layers of the same problem.
The Automation Cookbook includes AWS testing patterns using moto and testcontainers alongside 30+ production Python automation scripts. If you're rethinking your test infrastructure, the patterns there work with any of the tools covered here.
Top comments (0)