This is a cross-post. I wrote up the design philosophy behind Floci for the dev.to audience. For the full architecture, benchmarks, and SDK compatibility numbers, read the in-depth write-up here on the site: Introducing Floci.
Most AWS emulators make you pick a side: fast-but-fake (shallow mocks that pass your unit tests but never catch real integration bugs) or heavy-but-faithful (a giant container that boots in seconds and eats hundreds of MiB). Floci refuses that tradeoff.
The trick is a three-pattern architecture. Stateless services run in-process for instant responses. Analytics-style services lean on tiny embedded engines like DuckDB. The genuinely complex services (think PostgreSQL via RDS) spin up real Docker containers on demand. The guiding rule is simple: never reimplement an engine that already exists; wrap the real AWS API around the real thing. That is how Floci keeps a ~24 ms startup, ~13 MiB idle footprint, and a ~90 MB image while still feeling like real AWS. A service like Postgres taking ~3 seconds to start is an acceptable price for true fidelity.
Read it on dev.to
The full write-up lives here:
The Floci philosophy: stay tiny, feel like real AWS
Prefer the deep dive with architecture diagrams and benchmark methodology? That’s the Introducing Floci post.