Standing on shoulders: the stack that makes Floci start in ~24ms

Floci starts in 24ms and idles at 13 MiB of RAM.

That number gets attention, and it tends to obscure the real story. It isn't about one clever optimization. It's about four open-source projects that have been quietly perfecting their respective jobs for years, stacked on top of each other in a way that makes the whole thing possible.

Floci is a free, MIT-licensed AWS emulator. It speaks the AWS wire protocols on localhost:4566, emulates 45 services, and is verified by 1,925 SDK compatibility tests across Java, Python, Node.js, Go, and Rust. Here's the stack underneath it.

Netty, the async I/O substrate

is the layer where Floci uses things directly. It's Netty with ergonomics: an event loop, a router, protocol-specific APIs for HTTP, DNS, TCP, WebSockets, gRPC, all sharing the same threading model.

Floci uses Vert.x for two things that matter.

The HTTP router. AWS routing is weird. The same TCP endpoint serves REST-XML (S3), REST-JSON, x-amz-json-1.0 and 1.1 (DynamoDB), query-string protocol (older services), and EC2 query protocol. Vert.x's router gives you full control over dispatch without forcing a single framework's idea of what a controller looks like.

The embedded DNS server. Floci runs its own authoritative DNS on UDP/53 inside the container, so *.localhost.floci.io resolves to Floci's container IP on the Docker network. That's how virtual-hosted S3 (https://my-bucket.s3.localhost.floci.io/key) works from inside spawned Lambda containers with no extra setup. Tractable in Vert.x because HTTP, UDP, and TCP all share infrastructure: same event loop, same lifecycle. About 200 lines.

Quarkus, the framework layer

This is where Floci becomes a coherent application instead of a pile of libraries.

is Red Hat's downstream of