Floci: The Native Java AWS Emulator Built for the Post-LocalStack Era

A fast, MIT-licensed local AWS stack that trades feature gates for real containers, compatibility testing, and a surprising amount of Java performance.

9 min read • View on GitHub • More from floci-io

A laptop terminal launches a compact local cloud stack made of small container modules while a distant cloud sits in the background. The image explains Floci’s core idea: AWS-like work happens locally, with real services and containers instead of a heavy remote dependency.
Floci is not trying to impersonate AWS with a thin mock layer. It is trying to make a small local machine behave like a serious cloud test rig.

Local development against AWS services has always been painful. You either run real AWS (expensive, slow, requires an internet connection) or use an emulator. For years, LocalStack was the go-to choice — until they required auth tokens and locked down their community edition in early 2026. That gap is exactly what Floci fills.

Key Takeaways

The local AWS emulator category changed when the default option stopped feeling free and frictionless. That opened a gap for something leaner, more open, and more honest about what local development actually needs.

Portrait of Hector Ventura, the creator of Floci, rendered as a WSJ-style hedcut. The image anchors the origin story behind the project and shows the maintainer driving the reset in local AWS tooling.

The Local AWS Stack Changed

Floci makes sense because the old default got harder to justify. If a team wants local parity for SDK calls, IAM behavior, Lambda execution, and infrastructure tooling, a brittle mock is not enough, and a gated emulator feels like a tax.

OptionStartup and footprintFidelityTooling compatibilityTrade-off
Unit-level mocksVery lightLowOnly your test codeFast, but shallow and brittle
LocalStackBroader coverage, heavier runtimeHighStrongMore complete, but larger and less open
FlociSmall footprint, fast startupHigh for supported pathsDesigned to be drop-inNarrower than the biggest players, but deliberately lighter and free

Why Floci Is a Java Story, Not Just an AWS Story

The surprising part is not that Floci works. It is that it works with a modern Java stack that people still tend to file under heavy and slow. The project uses Java 25, Quarkus, and GraalVM native image to turn that stereotype into a performance argument.

That choice matters because local emulation lives or dies on friction. If the tool starts quickly, stays small, and still gives you a structured codebase, you can afford to keep it running during real development instead of treating it like a special test-only dependency.

A compact engine shrinks from a bulky build artifact into a small native binary while a stopwatch and memory gauge sit beside it. The illustration explains how Quarkus and GraalVM help Floci cut startup time and footprint.
Floci’s performance story is architectural, not cosmetic. The native-image build turns Java into a practical runtime for local infrastructure work.

The Three-Layer Model That Keeps the Emulation Honest

Floci’s architecture is simple enough to explain and strong enough to matter: controller, service, storage. The controller handles AWS wire protocols, the service layer owns behavior, and storage decides how state persists.

The core design is a layered execution path. Requests enter as AWS-shaped traffic, pass through behavior-specific code, and end in storage or real containers depending on the service.

That split is what makes the system legible. It also prevents the classic emulator problem where every service endpoint becomes a special case hidden in one giant handler.

AWS client or IaC tool
  -> wire protocol parser
  -> controller
  -> service layer
  -> storage backend or Docker-backed runtime
  -> response

Where Fidelity Comes From

Floci leans on real execution where it matters most. Lambda runs inside actual Docker containers, which means the local environment is not pretending to be compute. It is running compute.

The compatibility work is the real differentiator. API shape matters, but so do SDK quirks, CLI expectations, validation errors, event source mappings, and the rough edges that only show up when a tool is used the way developers actually use it.

Fidelity layerFloci approachWhy it matters
Protocol handlingAWS wire protocol parsing through the controllerLets SDKs and IaC tools talk to it naturally
Service behaviorDedicated service logic per AWS featureKeeps edge cases close to real AWS semantics
ExecutionReal Docker-backed containers for Lambda and related workloadsRaises trust for integration tests and networking behavior
StatePluggable storage with memory, persistent, and WAL modesGives teams a choice between speed and durability

The Compatibility Suite Is the Product

The `compatibility-tests/` directory is not just QA plumbing. It is the project’s thesis made visible. If the emulator cannot survive black-box AWS CLI checks, Terraform and OpenTofu coverage, and SDK-specific edge cases, the promise collapses.

That is why the breadth of the suite matters. It turns parity from a claim into a repeated measurement across languages and tools, which is exactly how infrastructure software earns trust.

Floci vs. the Usual Alternatives

QuestionFlociLocalStackMocks and stubs
Do you get real local execution?Yes, for supported services and Docker-backed pathsYes, but in a broader heavier platformNo, only simulated behavior in your test process
Is it free and open?MIT licensed and no gatekeepingCommunity access is more constrainedUsually free, but incomplete
Does it aim for parity?Yes, through compatibility tests and real container executionYes, with larger service coverageNo, it usually targets unit isolation instead
Does it fit offline local development?YesYes, though with more overheadSometimes, but not with AWS-like fidelity

The best way to read the comparison is not as a winner take all chart. It is a fit chart. If you want the widest catalog and are willing to pay the overhead, a larger platform still makes sense. If you want a lighter, open, local-first path with serious fidelity, Floci is the more interesting bet.

Who Floci Is For

Floci is for teams that care about integration behavior, not just green unit tests. That includes backend teams, platform teams, and startups that want local AWS parity without tying their workflow to a bigger vendor-controlled runtime.

It is also for anyone who wants AWS-shaped development to work offline, cheaply, and consistently. The project’s strongest idea is not that it imitates the cloud. It is that it makes the cloud feel small enough to fit on a laptop without turning fidelity into an afterthought.