Floci: emulating AWS locally with no account, no token and no quota

In March 2026 the localstack/localstack:latest image started requiring an account and a LOCALSTACK_AUTH_TOKEN. The temporary bypass — LOCALSTACK_ACKNOWLEDGE_ACCOUNT_REQUIREMENT=1 — stopped working on April 6.

The version going around is exaggerated, so here is precisely what changed: LocalStack still has a free plan, including one for non-commercial use with the same functionality as the old community image, and open source projects can request a free license. What disappeared isn't the zero price. It's being able to run docker run localstack/localstack without signing up.

For a developer working alone, that's an annoyance. For a CI pipeline inside an organization, it's one more secret to rotate, one more vendor in the threat model and one more legal step. That was enough for alternatives to appear, and the most direct one is Floci.

What it is

Floci is a family of local cloud emulators: MIT, no signup, no telemetry. One container per cloud, one port per container.

The detail that decides the migration is in the first row: port 4566 is the same one LocalStack uses. If your code already points there with an endpointOverride, there is nothing to change on the application side. Swap the image and you're done.

An emulator that picks its predecessor's port is telling you something about its strategy: it isn't competing for new adoption, it's competing for frictionless replacement.

The numbers the project publishes

These come from Floci's README, comparing itself against the LocalStack image. I didn't measure them. I'm reproducing them for what they are: the project's own benchmarks — exactly the kind of number to verify on your own machine before you cite it in a decision.

• Startup: ~24 ms against ~3.3 s
• Memory at rest: ~13 MiB against ~143 MiB
• Image size: ~90 MB against ~1.0 GB

The startup difference isn't marketing: it comes out of an architecture decision. Floci is built in Java and compiled to a native image, so it pays neither JVM startup nor interpreter startup. For an integration test that brings the container up and down for every suite, three seconds per run becomes minutes per day.

For stateful services — databases, persistent queues — Floci starts real containers underneath instead of simulating them. That's why the docker run mounts the Docker socket.

Trying it

docker run --rm -p 4566:4566 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  floci/floci:latest

And from another terminal, with the same AWS CLI as always:

aws --endpoint-url http://localhost:4566 s3 mb s3://prueba
aws --endpoint-url http://localhost:4566 s3 cp ./archivo.txt s3://prueba/
aws --endpoint-url http://localhost:4566 s3 ls s3://prueba/

The credentials don't matter: any pair of values works. That's precisely the point of a local emulator, and also the first thing that separates it from real AWS.

If you'd rather not handle containers by hand, the project ships an installer:

curl -fsSL https://floci.io/install.sh | sh    # macOS and Linux

irm https://floci.io/install.ps1 | iex          # Windows

As with any script you download and execute in a single command: read it first if it's going to run on a machine that isn't only yours.

In CI

The part that decides whether this makes it into a team or stays on one person's machine is the Testcontainers module. It requires Java 17+ and Docker:

<dependency>
    <groupId>io.floci</groupId>
    <artifactId>testcontainers-floci</artifactId>
    <version>${testcontainers-floci.version}</version>
    <scope>test</scope>
</dependency>

@Testcontainers
class S3IntegrationTest {

    @Container
    static FlociContainer floci = new FlociContainer();

    @Test
    void shouldCreateBucket() {
        S3Client s3 = S3Client.builder()
                .endpointOverride(URI.create(floci.getEndpoint()))
                .region(Region.of(floci.getRegion()))
                .credentialsProvider(StaticCredentialsProvider.create(
                        AwsBasicCredentials.create(floci.getAccessKey(),
                                                   floci.getSecretKey())))
                .forcePathStyle(true)
                .build();
        // …
    }
}

forcePathStyle(true) is not optional, and it's the mistake that costs the most time: without it the SDK builds URLs with the bucket as a subdomain — prueba.localhost — and that doesn't resolve.

Where to find it

Everything lives under the floci-io organization:

• floci-io/floci — the AWS emulator. This is the repo to read first: it has the list of 69 services and the comparison table.
• floci-io/floci-cli — the unified CLI for all four clouds.
• floci-io/floci-ui — web console for inspecting what you created.
• floci-io/testcontainers-floci — the Testcontainers module for Java and Kotlin, on top of JUnit 5.

The image is on Docker Hub as floci/floci.

When not to

This is where it pays to be honest, because an emulator that works well in the demo is the classic setup for a bad decision.

An emulator is not AWS. It reimplements the observable behavior of an API, not the system behind it. The differences show up exactly where they cost the most to discover: IAM semantics, eventual consistency, throughput limits, behavior under load, and anything that depends on how a real service degrades. If your test verifies that an IAM policy denies something, the local result is evidence of nothing.

It's a young project. It was born out of a March 2026 license change. It doesn't have the years of strange edge cases the thing it replaces accumulated, and the service count it advertises — 69 — tells you how many respond, not how faithfully. Before you rest an entire suite on it, test the services you actually use first.

The numbers are theirs. Startup, memory and size come from their own README. They're plausible and consistent with compiling to a native image, but they aren't an independent measurement.

With that said: for local development and for integration tests in CI, an MIT container that starts in milliseconds and asks for no credentials solves a real problem that appeared this year. As a drop-in replacement on the same port, the cost of trying it is one docker run.

What it doesn't do is save you a real environment. That still sits before production, and no emulator replaces it.