LocalStack has been the de facto OSS option for emulating AWS APIs locally. For many teams using AWS, the experience of “point the AWS SDK at port 4566 and you have a full stack on your laptop” was already the baseline, both in CI/CD and via docker-compose.

On March 23, 2026, however, the localstack/localstack repository was archived, and the Docker image was consolidated into a single unified image that now requires authentication. The code itself remains under Apache-2.0, but the repository is now a frozen reference, and the Community Edition pattern of “spin it up, no account needed” has effectively ended.

Around the same window, newcomers like MiniStack, Floci, kumo, and fakecloud launched in quick succession, and the community is now sorting through which one (or which combination) takes over the LocalStack slot in Q2 2026. This post organizes those candidates by license, AWS service coverage, compatibility level, migration cost, and maintenance health, then maps each to a workload.

What Happened to LocalStack

The short timeline.

• February 2026: Pricing was reworked and a Hobby (non-commercial) free tier was introduced
• March 23, 2026: The localstack/localstack repository was archived. Issues and PRs are closed, only Discussions remain open. The Docker image is now a single image merged with Pro, and LOCALSTACK_AUTH_TOKEN is required (the grace-period flag LOCALSTACK_ACKNOWLEDGE_ACCOUNT_REQUIREMENT=1 stopped working shortly after)

The code stays under Apache-2.0, so forks are technically possible. In practice, the LocalStack internals contain a wide custom implementation across many AWS APIs, and maintaining a fork is non-trivial. As a result, no major fork has materialized as of May 2026 in the way that Elasticsearch (OpenSearch), Terraform (OpenTofu), or Redis (Valkey) spawned community continuations. Instead, several from-scratch OSS projects have stepped up as replacement candidates.

The Candidate Map — Broad Emulators vs. Single-Service Tools

The pragmatic way to organize the candidates is by goal resolution, in two layers.

• Broad emulators (LocalStack-shaped): aim to reproduce the “point your SDK at port 4566 and many AWS APIs respond” experience. MiniStack, Floci, kumo, and fakecloud live here
• Test-side mocks: not a production-shaped local AWS, but a tool for swapping the AWS SDK inside tests. moto is the canonical option (its standalone server mode can also be used in a broad-emulator style)
• Specialized tools: built around fidelity for a single service. Amazon DynamoDB Local, ElasticMQ, and S3Mock belong here

A quick map first.

flowchart LR
    A[LocalStack-like experience] --> A1[MiniStack]
    A --> A2[Floci]
    A --> A3[kumo]

    B[API fidelity for supported services] --> B1[fakecloud]

    C[Unit-test centric] --> C1[moto]

    D[Single service only] --> D1[DynamoDB Local]
    D --> D2[ElasticMQ]
    D --> D3[S3Mock]

“Move the same docker-compose.yml with minimal change”, “for the services we use, behave as close to real AWS as possible”, “stay inside the test process”, “we only use S3 and SQS”: each of these forks lands on a different tool. The rest of the post walks through them in order.

The New Broad Emulators

MiniStack — Broad Coverage With Strong IaC Affinity

MiniStack is an AWS emulator under the MIT License. The repository lives at ministackorg/ministack, and you can run it via pip install ministack or the ministackorg/ministack Docker image. The README claims 40+ services, covering most of the APIs that used to be in the old LocalStack Community.

The design choices are worth highlighting.

• Listens on port 4566, so passing AWS_ENDPOINT_URL=http://localhost:4566 lets the AWS SDK, AWS CLI, Terraform, CDK, Pulumi, and CloudFormation work largely as-is
• LocalStack-compatible paths (the /etc/localstack/init/ready.d/*.sh init script directory, partial acceptance of LOCALSTACK_* environment variables) are deliberately preserved
• Testcontainers modules for Java and Python are available, so Spring Boot 3.1+ @ServiceConnection integrates @SpringBootTest smoothly
• Stateless AWS APIs run in-memory, but enabling SERVICES=rds spins up real PostgreSQL or MySQL containers underneath, so you can dial in real backends where they matter

That said, the official docs themselves call out the gaps: IAM policies are not enforced, some services are metadata-only, and EventBridge Scheduler does not auto-execute. If you need to reproduce the fine grain of real AWS, those are the things that can block a PoC.

Floci — Quarkus Native for Fast Startup

Floci is MIT-licensed, with the repository at floci-io/floci. It is built on Quarkus with GraalVM Native Image, so startup time and idle memory are unusually small. The README claims roughly 24 ms startup, 13 MiB idle, a 90 MB image, and 1,850+ automated compatibility tests across 6 SDKs and 3 IaC tools; these are vendor-reported numbers and worth treating as such.

The design is heavily biased toward being a LocalStack drop-in.

• Port 4566, wire protocol aligned with LocalStack, and LOCALSTACK_PARITY=true translates LocalStack environment variables automatically
• Stateless APIs (SSM/SQS/SNS/IAM/Kinesis, etc.) run in-process; stateful ones (S3/DynamoDB) use a storage abstraction with memory / persistent / hybrid / wal modes
• Lambda / RDS / ElastiCache / ECS / EKS / EC2 / MSK / OpenSearch / CodeBuild spawn real containers, so /var/run/docker.sock needs to be mounted
• Compatibility tests and Testcontainers modules ship for Java, Python, Node, and Go
• A proposal to integrate into Quarkus Dev Services is in motion, and in the Quarkus ecosystem Floci is becoming the default choice

The project itself only launched in early 2026, so edge-case compatibility is still being mapped out by users.

kumo — A Single Binary That Slots Easily into CI

kumo is MIT-licensed. It is developed by Japanese engineer sivchari, and the README advertises 76 implemented AWS services.

The biggest draw is how simple the distribution is.

• A single binary, or the ghcr.io/sivchari/kumo:latest Docker image
• Port 4566 for LocalStack compatibility; with AWS SDK for Go v2, calling BaseEndpoint("http://localhost:4566") is enough to redirect traffic
• In-memory by default; set KUMO_DATA_DIR to persist state via atomic writes to files such as s3.json, dynamodb.json, and iam.json
• CI/CD overhead is minimal; you can migrate a LocalStack workflow by swapping a single line of the image name in docker-compose.yml

The project is on the v0.x line, with frequent releases but effectively one maintainer. Before adopting it in an enterprise setting, it is safer to run a PoC that maps out which services have what depth.

fakecloud — Prioritizing API Fidelity

fakecloud is licensed under AGPL-3.0. The repository is at faiscadev/fakecloud. The GitHub README lists 30+ services and 2,400+ operations, so the breadth is narrower than Floci / MiniStack / kumo. What distinguishes it is how strongly it prioritizes behavioral parity with real AWS for the services it does cover.

Concretely:

• The official site advertises “100% Smithy conformance per implemented service”, “conformance tests generated from the Smithy model”, and “Terraform acceptance tests run in CI”
• --verify-sigv4 enables SigV4 signature verification; --iam soft|strict lets you graduate IAM enforcement
• Around 500 ms startup, ~10 MiB idle memory, and a ~19 MB binary
• First-party test SDKs are available for TypeScript, Python, Go, PHP, Java, and Rust

The AGPL-3.0 license deserves attention. Using it for internal local development and CI is generally fine, but bundling it into a product or providing it as a network service to third parties triggers AGPL’s obligations and is stricter than MIT or Apache-2.0. Loop in legal early if redistribution is in the picture.

Test-Side Mocks — moto

moto has been developed since 2014 under Apache-2.0, and its AWS API coverage is still arguably the broadest in the ecosystem. With 100+ services, it covers S3, SQS, SNS, DynamoDB, Kinesis, Lambda, Step Functions, EventBridge, API Gateway, CloudFormation, KMS, Secrets Manager, IAM, EC2, ECS, EKS, CloudWatch Logs, and more.

There are three ways to use it.

• The @mock_aws Python decorator: attach it to a function or test class to inject a mock in-process. No external process means startup overhead is effectively zero, which makes it the fastest path for Python tests
• ThreadedMotoServer: stands up an HTTP server inside the same process so the same Python process can hit it through the AWS SDK via endpointOverride
• The motoserver/moto Docker image: an HTTP server on port 5000. Languages other than Python (Java, Go, Node.js, Terraform, etc.) can connect through AWS_ENDPOINT_URL

moto is most accurately framed as a place to rethink your test strategy, not as a drop-in LocalStack replacement. If you were used to “stand up a wide AWS via docker compose and run integration tests against it” with LocalStack, moto sits a little differently. It rewards moving tests closer to the code, making them blistering fast with in-process decorators, and falling back to standalone server mode when language-agnostic access matters.

Between community size, release cadence, and sponsorship, getmoto/moto remains one of the healthiest maintenance stories in this space.

The Single-Service Tools

When you do not need a horizontal local AWS (say, “only S3”, “only SQS”, or “only DynamoDB”), specialized tools are simpler to operate than a broad emulator.

Amazon DynamoDB Local — Official from AWS

DynamoDB Local is AWS’s official local implementation of DynamoDB. It runs from the amazon/dynamodb-local Docker image on port 8000, and -sharedDb -dbPath lets you persist via SQLite. It works with AWS NoSQL Workbench too. Because it is official and reproduces DynamoDB semantics faithfully, the pragmatic split in enterprise settings is often “let the official local handle DynamoDB only”.

ElasticMQ — A Mature SQS-Compatible Implementation

ElasticMQ is Apache-2.0, built by SoftwareMill on top of Pekko. There is the standard softwaremill/elasticmq Docker image and a GraalVM-native build (softwaremill/elasticmq-native), and JVM projects can also embed it directly. It reproduces FIFO queues, DLQs, visibility timeout, and long polling faithfully, and for SQS specifically it is ahead of Floci / MiniStack on fidelity, maturity, and performance.

S3Mock — A Partial S3 Implementation Built for JVM Tests

S3Mock is Apache-2.0, written by Adobe on Spring Boot. Its integration with Docker / Testcontainers / JUnit 5 / TestNG is exceptionally strong, which makes it the first pick when a Java project needs S3 and nothing else. The caveats: path-style only, presigned URLs are accepted but not verified, and KMS only validates ARNs (no actual encryption). Whether those limitations collide with your application flow is worth checking up front.

MinIO — An S3-Compatible Object Store

MinIO is an AGPL-3.0 S3-compatible object store with near-full coverage of PutObject, GetObject, multipart upload, bucket policy, and versioning. For local development and CI use, you can generally use it without trouble; but bundling the binary into a product or offering it as a network service to third parties exposes you to AGPL’s obligations, and Apache-2.0 or MIT alternatives carry less legal overhead.

There is also a maintenance concern: the minio/minio repository was archived by its owner on April 25, 2026, and is now read-only. You can keep using the latest Docker image internally, but the assumption that you can track ongoing maintenance from this OSS repository no longer holds. For new adoption of an S3-only local store, an Apache-2.0 / MIT alternative that is still maintained, such as S3Mock (Apache-2.0), is the more pragmatic pick.

Comparison Table

A condensed view from an operations perspective.

Candidate	License	Service Coverage	Compatibility Notes	Migration Cost from LocalStack
MiniStack	MIT	Broad (40+)	Port 4566; IaC stacks work via AWS_ENDPOINT_URL; LocalStack-compatible init script paths	Small to medium. IAM not enforced
Floci	MIT	Medium to broad (47)	Port 4566; LOCALSTACK_PARITY auto-translates env vars; container services spawn real Docker	Small
kumo	MIT	Broad (76)	Port 4566; KUMO_DATA_DIR persists state; explicit Go SDK v2 compatibility	Small
fakecloud	AGPL-3.0	Medium (30+)	Port 4566; Smithy-derived conformance; SigV4 verification and strict IAM mode	Small to medium. Verify AGPL implications
moto	Apache-2.0	Very broad (100+)	Decorator / ThreadedServer / Docker server; multi-language access via SDK AWS_ENDPOINT_URL	Medium to large (rethinks test strategy)
DynamoDB Local	AWS official	DynamoDB only	Official AWS implementation, SQLite persistence	Small (single-service assumption)
ElasticMQ	Apache-2.0	SQS only	Embeddable; covers FIFO / DLQ / visibility timeout	Small
S3Mock	Apache-2.0	S3 only (partial)	Strong JUnit / Testcontainers integration; path-style only	Small to medium

Service counts wobble between official sites, READMEs, and release notes, and especially for the four newcomers (MiniStack, Floci, kumo, fakecloud) the marketing number does not always match implementation depth. The safer adoption criterion is “how many of the AWS APIs you actually use does the candidate pass in a PoC”.

Use-Case Selection Guide

A Drop-In Replacement with Minimal Change

If your goal is to swap the image name and a few environment variables in docker-compose.yml and call it a day, Floci and MiniStack are the leading candidates. Both listen on port 4566 and preserve LocalStack’s init script paths and a subset of its environment variables. Java / Spring Boot projects tend to benefit from Floci’s Quarkus affinity; Python / IaC-heavy projects benefit from MiniStack’s straightforward AWS_ENDPOINT_URL story.

Prioritizing API Fidelity for the Services You Use

If your set of AWS services is narrow but you want them to behave as close to real AWS as possible, fakecloud is the candidate. With Smithy-derived conformance, SigV4 verification, and strict IAM mode, it minimizes the kind of drift where things pass locally but fail in production. Confirm with legal that AGPL-3.0 is acceptable for your usage pattern.

Java / Spring Boot Projects

For Java / Spring Boot heavy projects, how cleanly the tool integrates into @SpringBootTest via Testcontainers matters a lot. Both Floci and MiniStack ship official Testcontainers modules and slot naturally into the Spring Boot @ServiceConnection pattern. A solid enterprise setup is the hybrid: Floci or MiniStack as the base, the official AWS DynamoDB Local for DynamoDB, and ElasticMQ for higher SQS fidelity.

Lightweight Python Tests

When you do not want any external process and just want a mock injected in-process, moto’s decorator is still the fastest and lightest. If the move is “stop pushing integration tests further downstream and run them closer to the code, faster”, switching the design to moto is the cleaner answer rather than replacing LocalStack like-for-like. For mixed-language test suites, you can stand up a single motoserver/moto instance and have every language’s AWS SDK target it via AWS_ENDPOINT_URL.

A Single Service Only

When the requirement narrows to “just S3”, “just SQS”, or “just DynamoDB”, decomposing into DynamoDB Local / ElasticMQ / S3Mock is simpler to operate than a broad emulator. AWS-official and Apache-2.0 specialized tools tend to be ahead of newcomers in both maintenance health and edge-case fidelity for the service they focus on.

A Migration Checklist from LocalStack

Newcomers ship fast, but edge-case compatibility is still being mapped out and is worth observing for another six to twelve months. Rather than flipping the switch in one shot, the lower-risk path is something like this.

• Inventory the AWS services and APIs in use: grep for SERVICES= in docker-compose.yml, AWS CLI invocations under /etc/localstack/init/, and endpoint_url references in test code
• Identify LocalStack-specific dependencies: spots that rely on LocalStack proprietary surfaces (Cloud Pods, persistence snapshots, Resource Browser) rather than pure AWS APIs
• Pin down golden tests: codify the must-not-break scenarios for S3 / SQS / DynamoDB / Lambda / IAM / STS as golden tests first
• Run a PoC: pick two or three candidates, branch the repo, swap only the image via docker-compose.override.yml, and compare existing test pass rates, startup time, and CI stability
• Document deltas in IAM / SigV4 / presigned URLs / path-style S3 / persistence / reset APIs: newcomers differ here, so making the deltas explicit in tests pays off later
• Run in parallel in CI: keep LocalStack and the candidate side by side for a while and surface the diffs before cutting over
• Keep a rollback-able configuration: leave the compose / env / IaC profiles in place after the switch so you can fall back if needed

flowchart TD
    A[Inventory AWS services and LocalStack dependencies] --> B{Mostly a single service?}
    B -- Yes --> C[Evaluate specialized tools<br/>S3Mock / ElasticMQ / DynamoDB Local]
    B -- No --> D{What is the top priority?}
    D -- LocalStack-shaped drop-in --> E[PoC Floci / MiniStack / kumo]
    D -- API fidelity for covered services --> F[PoC fakecloud]
    D -- Lighter test path --> G[Redesign around moto]
    C --> H[Author golden tests]
    E --> H
    F --> H
    G --> H
    H --> I[Verify IAM / SigV4 / persistence / S3 URL deltas]
    I --> J[Parallel-run in CI]
    J --> K{Deltas acceptable?}
    K -- No --> L[Swap candidate or split per service]
    K -- Yes --> M[Cut over the development flow]

Notes on Security and Licensing

A few things worth keeping front of mind when adopting any of the newcomers.

Licenses split across the field: MIT (MiniStack, Floci, kumo), Apache-2.0 (moto, ElasticMQ, S3Mock), and AGPL-3.0 (fakecloud, MinIO). Internal local development and CI usage rarely runs into trouble even with AGPL, but bundling into a product or offering “to third parties over the network” via SaaS triggers AGPL’s obligations and a legal review. Maintaining an SPDX list of adopted candidates makes those conversations easier later.

Docker socket mounting is required when Floci or MiniStack runs Lambda or container-based services. This is a classic container-escape vector, so for shared CI runners (self-hosted GitHub Actions and similar), consider isolating jobs that do not need the socket or moving to rootless Docker.

When pairing this stack with AI coding agents (Claude Code, Codex CLI, and friends), spell it out in CLAUDE.md / AGENTS.md: “This repo uses Floci (or MiniStack), not LocalStack; port 4566; AWS_ENDPOINT_URL=http://localhost:4566; no auth”. LocalStack’s documentation is heavily represented in agent training data, so without an explicit instruction the agent will reach for localstack/localstack in your docker-compose.yml by default.

Wrap-Up

LocalStack’s archival rewrites the map for emulating AWS locally in 2026. For a LocalStack-shaped experience, Floci and MiniStack lead; for API fidelity over a narrower service set, fakecloud; for lightweight Python tests, moto; and for single-service work, decompose into DynamoDB Local / ElasticMQ / S3Mock. That is the steadiest framing at the moment. The newcomers all have momentum, but they are still young projects. Especially for enterprise use, the realistic posture is to lay down golden tests, run candidates in parallel for six to twelve months, and let the winner emerge.

That’s all from someone who sorted through OSS alternatives in the wake of LocalStack’s archival. From the gemba.