Floci: The Free LocalStack Alternative That Starts in 24ms and It's Better Than What You Lost

26 AWS services. A 24-millisecond startup. Zero dollars. Here's how it works — and why it matters.

On March 23, 2026, a lot of developers had a bad morning.

They pushed to main, CI kicked off, and their pipelines started failing. Not because of a bug they wrote. Not because of an infra outage. But because LocalStack — the tool they'd been quietly depending on for years to emulate AWS services locally — had started requiring an authentication token to run. No token, no container. No container, no tests. No tests, no deployment.

The LocalStack community edition had been sunset. Quietly, decisively, and with very little runway.

Teams that had spent years building test suites around localhost:4566 were suddenly staring at a $39/month bill or a major refactor. Some paid. Some ripped out their local AWS setup entirely. And some — a growing, vocal, increasingly energized chunk of the developer community — went looking for an alternative.

They found Floci. And it turns out, it's better than what they lost.

What Exactly Is Floci?

Floci (pronounced like "flocky," named after cirrocumulus floccus — those light, puffy, popcorn-shaped clouds you see on a clear afternoon) is a free, open-source, MIT-licensed local AWS emulator. It runs as a single Docker container, exposes port 4566 exactly like LocalStack did, and speaks the same AWS wire protocol that every SDK, CLI, and IaC tool expects.

You point your code at http://localhost:4566 instead of https://aws.amazon.com, and everything just works. Your S3 buckets, your DynamoDB tables, your Lambda functions, your SQS queues — all running on your laptop, with no AWS account involved, no cloud credits burned, no data leaving your machine.

The pitch is simple: develop and test against real AWS APIs, completely offline, completely free, forever.

What makes Floci interesting isn't just that it exists. It's how it's built — and what that means for the numbers.

The Engineering Behind the Speed

Here's the thing that surprises people first: Floci starts in ~24 milliseconds.

Not 24 seconds. 24 milliseconds. LocalStack, by comparison, took around 3.3 seconds. That's a 137x difference. It doesn't sound like much until you're running a full integration test suite in CI that spins up and tears down the emulator dozens of times. Suddenly you're talking about the difference between a 4-minute test run and a 2-second one.

The reason for this gap comes down to a fundamental architectural choice. LocalStack was built in Python with a JVM backend — a stack that's powerful and flexible but carries significant startup overhead. Floci is built entirely in Java on top of Quarkus, the cloud-native Java framework, and compiled to a GraalVM Mandrel native binary.

What does "compiled to a native binary" mean in practice? It means the entire application — all the service logic, the routing, the storage layer — gets compiled ahead-of-time into a standalone executable. There's no JVM to boot, no bytecode to interpret, no Python runtime to initialize. The binary starts like a command-line tool. Fast, lean, and predictable.

The result:

13 MiB of idle RAM. For context, a browser tab uses more memory than the entire Floci emulator running 26 AWS services simultaneously.

How Does It Actually Work?

Under the hood, Floci is a single HTTP server sitting on port 4566. Every AWS SDK call — whether it's from Python's boto3, Node's @aws-sdk, Java's SDK v2, the AWS CLI, Terraform, or CDK — is just an HTTP request with specific headers and a body in the AWS wire protocol format. Floci intercepts those requests, routes them to the right service handler, and returns a response that's wire-compatible with what real AWS would send back.

The architecture splits services into three tiers, which is worth understanding because it explains both Floci's capabilities and its design tradeoffs.

Tier 1: In-Process Stateless Services

Services like SQS, SNS, IAM, STS, KMS, Secrets Manager, Cognito, Kinesis, EventBridge, CloudWatch, Step Functions, CloudFormation, SES, and API Gateway all run entirely in-process. There are no external dependencies. They're pure Quarkus request handlers that process inputs, update state, and return responses. This is why startup is so fast — none of these services need to launch anything external. They're just code paths that wake up when the binary starts.

Tier 2: In-Process Stateful Services

S3 and DynamoDB (including DynamoDB Streams) also run in-process, but they're separated conceptually because they manage significant state: objects, tables, indexes, streams. Floci supports four storage modes for these services:

• memory — ephemeral, fastest, default. Perfect for tests that should start clean every time.
• persistent — state survives container restarts. Good for long-running local development.
• hybrid — mix and match per service. Keep DynamoDB persistent, SQS ephemeral.
• wal — write-ahead log mode for durability guarantees.

Tier 3: Container Services — The Interesting Part

This is where Floci does something genuinely clever. For Lambda, ElastiCache, RDS, and ECS, Floci doesn't simulate or mock the service behavior. It talks to your local Docker Engine and spins up real containers.

When you invoke a Lambda function, Floci launches an actual container running the Lambda runtime image, passes the event payload in, and returns the response. Your Lambda code runs for real, in the actual runtime environment. When you provision an ElastiCache cluster, Floci starts a real Redis or Valkey container. When you create an RDS instance, you get an actual PostgreSQL or MySQL database — one you can connect to with any JDBC client.

This matters for fidelity. You're not testing against a simplified mock of Lambda's execution model — you're testing against the actual runtime. And critically, IAM authentication and SigV4 request signing work exactly as they do in production AWS, including for the container-backed services.

The complete request flow looks like this:

Your app (any SDK, any language)
         │
         │ HTTP :4566 (AWS wire protocol)
         ▼
  ┌──────────────────────────────────┐
  │   HTTP Router (JAX-RS / Vert.x) │
  └──────────────┬───────────────────┘
                 │
       ┌─────────┼──────────┐
       ▼         ▼          ▼
  Stateless  Stateful   Container
  Services   Services    Services
  (in-proc)  (in-proc)     │
                           │ Docker API + IAM/SigV4
                           ▼
                    Real containers
                  (Lambda / RDS /
                ElastiCache / ECS)

What Services Are Covered?

As of mid-2026, Floci supports 26+ AWS services with 1,873 automated compatibility tests. Here are the highlights — and the services notably absent from LocalStack's free tier that Floci includes for free:

Core services (fully implemented, in-process): S3, DynamoDB + Streams, SQS, SNS, IAM (65+ ops), STS, KMS, Secrets Manager, SSM Parameter Store, CloudWatch Logs + Metrics, EventBridge, Step Functions, CloudFormation, ACM, SES, OpenSearch, Kinesis.

Services LocalStack Community never offered — that Floci does, free:

• API Gateway v2 / HTTP API — the modern, cheaper, faster API Gateway variant; gated behind LocalStack's paid tier
• Cognito — user pools, app clients, auth flows, JWKS and OpenID well-known endpoints; also gated in LocalStack
• ElastiCache — real Redis/Valkey containers with IAM auth and SigV4 validation
• RDS — real PostgreSQL and MySQL instances with IAM auth and JDBC compatibility
• ECS — 58 operations covering clusters, task definitions, services, and capacity providers

Compatibility Testing: More Serious Than It Looks

One thing that separates Floci from a side project is the companion floci-compatibility-tests repository — a dedicated multi-SDK test suite that verifies Floci's behavior against real AWS SDK expectations:

Nearly 1,900 tests across 9 SDKs and IaC tools. This is not "it works on my machine" open source. It's a meaningful engineering investment in correctness, and it shows.

Pros and Cons

No tool is perfect. Here's an honest look at where Floci shines — and where it has real limitations.

✅ The Good

It's genuinely, dramatically fast. 24ms startup changes how you think about integration tests. Feedback loops that previously felt heavy can now feel nearly instant.

It's tiny. 90 MB image, 13 MiB idle RAM. It fits on the cheapest CI runners, doesn't compete with your IDE for memory, and pulls fast even over slow connections.

Real containers for Lambda, RDS, ElastiCache, and ECS. This is a significant fidelity win. Bugs that only surface in real runtime environments get caught locally, before they reach staging.

It covers more than LocalStack Community ever did. Cognito, API Gateway v2, RDS, ElastiCache, ECS — all included, all free.

MIT license, with an explicit forever commitment. The project commits to never requiring auth tokens or feature gates. For something embedded in every developer machine and CI runner, license certainty is genuinely important.

Zero friction migration from LocalStack. Same port, same wire protocol. In most cases, migration is changing one line: the endpoint URL.

Flexible storage modes. The ability to mix persistent and ephemeral storage per-service is a thoughtful design for real-world dev workflows.

❌ The Limitations

Still relatively young. The project is under active development — fast-moving, but that also means occasionally breaking. Pin to specific release tags in CI rather than floating on latest.

Not 100% AWS parity — and it never will be. Emulators are approximations. Edge cases in AWS's behavior, quirks in specific SDK versions, and niche service operations can reveal gaps. Always validate against real AWS before production deployments.

Container-backed services add setup complexity. Lambda, RDS, ElastiCache, and ECS require access to your Docker socket. This is fine for local dev but can complicate Kubernetes-based CI runners, Docker-in-Docker setups, and certain sandboxed environments.

No web dashboard. LocalStack Pro had a UI for browsing resources. Floci is CLI and API only — useful to know before you migrate.

The ecosystem is still catching up. LocalStack had years of Stack Overflow answers, blog posts, and community knowledge. Floci's community is growing fast, but the depth of public documentation and third-party resources is still maturing.

Use Cases: Where Floci Actually Shines

Local Development Without a Cloud Account

The foundational use case. Develop and test AWS-dependent code without ever touching real AWS — no credentials to rotate, no accidental resource creation, no "wait for the deploy" inner loop. Point your app at localhost:4566 and iterate freely.

Fast CI/CD Integration Testing

At 24ms startup and 13 MiB RAM, Floci is arguably the first AWS emulator that's fast enough to use in tight feedback loops. Run it as a sidecar container in your CI pipeline, execute your full integration test suite, tear it all down. The overhead is nearly invisible.

Air-Gapped and Offline Environments

Regulated industries — government, financial services, healthcare, defense — often prohibit developer machines from making outbound connections to external cloud providers. Floci makes it possible to develop against AWS APIs in fully offline environments. No outbound calls, no telemetry, no auth tokens phoning home to a SaaS service.

Training and Education

Running AWS workshops, internal training programs, or university courses? Floci is an ideal sandbox. Students can experiment with S3, DynamoDB, Lambda, and API Gateway without AWS accounts, and instructors don't have to worry about runaway costs or cleanup.

Security Research and Penetration Testing

For security engineers auditing AWS-native applications, Floci provides a safe, isolated environment to reproduce misconfigurations, test IAM policy behavior, and validate SigV4 auth flows without touching production or staging infrastructure. The IAM implementation (65+ operations), full STS support, and real container runtimes make it viable for non-trivial auth and injection testing scenarios — relevant territory for anyone doing WAPT or AIRT work on cloud-native systems.

Microservices and Event-Driven Architecture Development

Floci's support for SQS, SNS, EventBridge, Kinesis, Lambda ESM triggers, and DynamoDB Streams makes it particularly strong for event-driven systems. You can wire a complete async pipeline — producer → SQS → Lambda → DynamoDB → DynamoDB Streams → another Lambda — entirely locally, with real execution at every step. No mocks in the critical paths.

The Pattern This Fits Into

It's worth stepping back for a second.

Redis changed its license. Valkey appeared, hosted by the Linux Foundation. Terraform went Business Source License. OpenTofu materialized. LocalStack went paid. Floci emerged.

Three times in 2026, a widely-used developer infrastructure tool shifted away from its free users, and three times the community responded with a credible, production-quality open-source alternative. Each time faster than the last.

The sustainability problem on the vendor side is real — building and maintaining infrastructure software is expensive, and LocalStack's co-CEOs wrote that the change was necessary to "sustainably invest in the platform." But the risk on the user side is equally real: building your CI pipelines and development workflows on a free tier that can disappear is infrastructure debt with a very uncertain maturity date.

Floci's explicit commitment — MIT license, no auth tokens, ever — is a bet on the other side of that equation. Whether the project can sustain that commitment over years will depend on community contributions, sponsorships, and perhaps enterprise support offerings down the road. But for now, the commitment is clear, the code is public, and the 10,000+ GitHub stars in under two months say something about how much the community wanted exactly this.

Getting Started in Under Two Minutes

# docker-compose.yml
services:
  floci:
    image: hectorvent/floci:latest
    ports:
      - "4566:4566"
    volumes:
      - ./data:/app/data

docker compose up -d

export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test

aws s3 mb s3://my-bucket
aws sqs create-queue --queue-name my-queue
aws dynamodb create-table \
  --table-name Users \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

Any credentials work. Any region works. No account required, no token to rotate, no wait.

Resources

• GitHub: github.com/floci-io/floci
• Documentation: floci.io
• Compatibility tests: github.com/floci-io/floci-compatibility-tests
• Docker Hub: hub.docker.com/r/hectorvent/floci
• Community Slack: Join the workspace

Floci is MIT licensed and free forever. If you're still running LocalStack and wondering whether the migration is worth it — it probably takes less time than LocalStack's boot sequence.