DEV Community: Hector Ventura

Why Floci is built in Java (and why that's the right call in 2026)

Hector Ventura — Sat, 16 May 2026 18:35:05 +0000

I get this question every week:

"Why did you build Floci in Java? Why not Go, Rust, or Python like LocalStack?"

It's a fair question. And the short answer is: the constraints picked the language, not the other way around.

The constraints came first

Before I wrote a line of code, I knew what Floci had to be:

24ms cold start, small memory at idle. Otherwise CI pipelines skip it.
One statically-linked binary in a ~90 MB image. No bundled interpreter, no runtime to install.
Real concurrency. Floci has to handle SQS long polling, Lambda containers, RDS proxying, DynamoDB Streams — all at the same time.
Maintainable for years, by contributors who aren't me.

Those five constraints knock most languages out before personal preference enters the picture.

Java in 2026 isn't the Java you remember

If your last serious Java was Spring Boot in 2015, the language has moved.

From Java 8 to Java 25 (the current LTS), the highlights that actually matter:

Virtual threads (Java 21, mature in 25) — millions of lightweight threads, no more thread pool tuning. For an emulator handling concurrent SQS pollers, Lambda invocations, and DB proxies, this is transformative.
Records, sealed classes, pattern matching — what used to take 30 lines of boilerplate is now 1. Modeling AWS request/response types becomes a pleasure instead of a chore.
Text blocks, switch expressions, var — the language reads like a modern language now, not an artifact of 1995.
Compact object headers (Java 25) — 8–12% memory savings across the board, for free.
Faster startup, smaller footprints every release — class data sharing, ahead-of-time profiling, generational ZGC. The JVM in 2026 is a different beast.

Java didn't stand still; the ecosystem just stopped talking about it.

Then there's the runtime story, Quarkus + GraalVM:

Quarkus changed the runtime model entirely. It does at build time what classic Java does at startup. Reflection, classpath scanning, dependency injection: all resolved when you compile, not when the container boots.

GraalVM then compiles that build-time-prepared application into a native binary. The benefits, concretely:

No JVM at runtime. No class loader, no warmup, no JIT pause on first request. The binary is the runtime.
24ms cold start vs 1–3 seconds for a typical JVM app. ~100× faster.
~13 MiB idle memory vs hundreds of MB for a JVM. ~10–30× smaller.
~90 MB Docker image vs ~250 MB for a JRE-based image, often more once you add libraries.
No CVE surface from a runtime you didn't write. No bundled OpenSSL, no Python interpreter, no Node... just the binary.
Statically linked. Runs on scratch or distroless base images if you want.

That's the part most people miss when they hear "Java." Floci doesn't carry a JVM. There is no JVM in the image. There's a binary.

Underneath Quarkus sits a stack that's been battle-tested for over a decade: Netty for non-blocking I/O (the same library powering gRPC, Cassandra, and most of the Java networking world), Vert.x for reactive routing, and Jakarta EE standards (JAX-RS, CDI) — boring in the best sense, with tooling and patterns everyone already knows.

This isn't a bet on a trendy stack. It's a bet on infrastructure that AWS, Netflix, and LinkedIn have been running in production for years.

Why not Python (LocalStack's choice)?

Python is great. I use it for scripts, tooling, and ML work all the time. But for an emulator that needs to be small, fast, and concurrent, the language's strengths and Floci's needs don't quite line up.

The numbers tell the story:

	Floci	LocalStack
Image size	~90 MB	~1 GB
Idle memory	~13 MiB	~500 MB
Cold start	~24 ms	15–30 s

That's roughly 10× smaller, 40× less RAM, and 1000× faster startup. Even a thoughtfully built Python emulator pays for the interpreter, the standard library, and the dependency tree — on disk and at startup. A GraalVM native binary doesn't carry any of that. The runtime is the binary.

There's also the concurrency story. Floci has to handle SQS long polling, Lambda containers, RDS proxying, and DynamoDB Streams simultaneously. In Java that's the default model. In Python it means navigating async/multiprocess gymnastics around the GIL — workable, but more friction.

LocalStack made a reasonable choice for what Python is good at: fast iteration on AWS API surface coverage. The price shows up downstream in the auth-token-walled "Pro" tier that pays for the engineering needed to keep a Python runtime fast and stable at that scope.

Floci goes the other way. The runtime is small because the language let me make it small.

And yes, I know Java well

Last point, because it's honest: I've been writing Java for 18+ years. When I'm debugging a wire-protocol mismatch at 11pm on a Sunday, I'm not fighting the language. I'm reading the AWS SDK source and writing the deserializer. The language is invisible.

A maintainer who fights their own tools doesn't ship. Floci ships because the stack and I have been working together for nearly two decades.

TL;DR

Java + Quarkus + GraalVM → 24ms startup, 13 MiB idle, single 90 MB binary
Built on Netty, Vert.x, and Jakarta EE — boring, proven infrastructure
Python's strengths (rapid iteration, scripting) aren't Floci's needs
18 years of Java experience means I ship features instead of debugging language weirdness

The constraints picked the stack. The stack has held up.

🔗 github.com/floci-io/floci
📚 floci.io/floci
💬 floci.slack.com

Jdjdbd

Hector Ventura — Sat, 09 May 2026 20:40:59 +0000

``bzjxbxj

The Floci philosophy: stay tiny, feel like real AWS

Hector Ventura — Sat, 09 May 2026 20:24:50 +0000

Fast and fake. Tiny, instant, until your code touches a real engine and the abstraction cracks.
Heavy and faithful. Closer to AWS, but a 3-second startup, hundreds of MB, a bundled Python runtime that turns every CI job into a slow morning.

I built Floci to refuse the choice. One principle:

Be the lightest thing possible. Be real where it counts.

The two halves of every AWS service

Read enough AWS API docs and you notice every service has two parts:

A control plane: "create this bucket, list my queues." Just CRUD over JSON or XML. The hard part is wire-protocol fidelity.
A data plane: "run this Lambda, connect to this database, query this Redis." This is where the real engine lives. Faking it works until it doesn't.

The control plane has no excuse to be heavy. The data plane has no excuse to be fake.

So Floci does both, on purpose, in different layers.

How it's structured

┌───────────────────────────────────────────┐
│  Floci core, Quarkus native binary               │
│  24 ms startup · 13 MiB idle                     │
│                                                  │
│  All control planes + stateless services         │
│  (S3, SQS, DynamoDB, IAM, KMS, ...)              │
└─────────────────┬─────────────────────────┘
                  │ Docker socket, on demand
                  ▼
┌───────────────────────────────────────────┐
│  Right-sized engines per service                 │
│                                                  │
│  Tiny sidecars:                                  │
│   • Athena, Firehose → floci-duck (DuckDB).     │
│                                                  │
│  Heavy real engines:                             │
│   • Lambda → real container                     │
│   • RDS    → real Postgres / MySQL              │
│   • Cache  → real Redis / Valkey                │
│   • MSK    → real Kafka                         │
└───────────────────────────────────────────┘

One tiny core. Real engines pulled in only when you actually use the service that needs them.

Three patterns, not two

The interesting part of the design is that there are three patterns, not the usual two. Each picks the smallest thing that gives you real behavior:

1. Stateless / metadata → in-process.
S3, SQS, DynamoDB, IAM. There's no engine to fake, just specs to implement correctly. Floci does it in 13 MiB.

2. Small embedded engine exists → tiny sidecar.
Athena doesn't need a Presto cluster. It needs correct SQL execution over data in S3. So Floci uses floci-duck, a small Rust binary wrapping DuckDB. Real columnar SQL, no JVM, no Hive metastore. The same sidecar powers Firehose's Parquet conversion. That's the philosophy at its purest: pick the lightest real engine.

3. No embeddable substitute → real heavy engine.
RDS, ElastiCache, MSK, OpenSearch, Lambda. Your code speaks PostgreSQL or RESP or Kafka or runs as actual containers, there's no faking it. Floci spins up the real thing on demand and gets out of the way.

The rule across all three: never reimplement an engine that already exists. Glue the AWS API onto it, then disappear.

What this buys you

Lightweight isn't marketing. A 24ms cold start means you spin Floci up per-test without thinking. ~13 MiB at idle fits free-tier CI runners. ~90 MB image is auditable. docker compose up finishes before you've alt-tabbed.

Fidelity isn't a checkbox. Lambda runs in real Lambda runtime images. RDS speaks real PostgreSQL. ElastiCache speaks real RESP. Athena runs real SQL through DuckDB against your real S3 data. If your test passes, your code actually works.

The tradeoffs I accept

Floci needs the Docker socket for engine-backed services. Fair deal.
Some services start slower than the core. Postgres takes a few seconds to boot. Floci itself is 24ms, but CreateDBInstance takes as long as Postgres takes. No way around that without lying.

These are the price of not lying to you.

Why it matters

Every emulator decision comes down to: do you want your tests to tell you the truth?

A bloated emulator gets skipped. A fast-but-fake one passes tests that fail in production. Floci's whole architecture is built to dodge both ends, pick the smallest real thing for every service, and never the bloated thing that pretends.

That's it. The rest is just code.

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

🔗 github.com/floci-io/floci
📚 floci.io/floci
💬 floci.slack.com

If you've ever shipped a bug because a test mock lied to you. I'd love to know which service did it. That's what Floci's roadmap is built from.

Floci (LocalStack alternative) storage modes: pick the right tradeoff per service (and never pay for it)

Hector Ventura — Sun, 03 May 2026 19:29:06 +0000

State that survives a docker compose down is one of those things you don't think about, until your test suite needs it, your local dev needs it, and your CI pipeline absolutely doesn't.

LocalStack handles persistence with one switch (PERSISTENCE=1) and it's a Pro-only feature. Floci ships four storage modes, all free, all in core, with per-service overrides. Pick the right tradeoff for the job.

The four modes at a glance

Mode	Survives restart	Write behavior	Best for
`memory`	❌	Pure RAM	CI, unit tests, ephemeral integration tests
`hybrid`	✅	Async flush to disk	Local development (the sweet spot)
`persistent`	✅	Sync write on every change	"Don't lose my last write" workflows
`wal`	✅	Append-only log + compaction	High-throughput durable workloads

You set a global default, and override per service when one needs different behavior. That's it.

When to use each

`memory` (default) for CI and ephemeral tests

# docker-compose.yml
services:
  floci:
    image: floci/floci:latest
    ports: 
      - "4566:4566"
    environment:
      FLOCI_STORAGE_MODE: memory

Everything stays in RAM. Container restarts wipe the slate. Fastest possible writes, smallest possible footprint.

This is the right answer for almost every CI pipeline. Each test run starts clean, you don't manage volumes, and you don't fight stale state from a previous job. Combined with Floci's 24ms cold start and 13 MiB idle footprint, you can spin up a fresh emulator per test class without thinking.

`hybrid` for local development

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

Reads and writes hit memory. A background flush moves data to disk every ~5 seconds. Container restarts pick up where you left off.

This is the mode I run locally. It feels exactly like memory while you're working, no I/O latency on writes, but docker compose down doesn't nuke your seeded test data. You spend less time re-running setup scripts.

`persistent` when losing the last write hurts

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

Every change syncs to disk before responding. Slower writes, but if Docker hard-kills the container at the wrong moment, the data that was acknowledged is genuinely on disk.

Reach for this when you're building something where "did this actually save?" matters, like reproducing a production data corruption issue, or running a long-running local script you don't want to redo.

`wal`: for high-write workloads that still need durability

# docker-compose.yml
services:
  floci:
    image: floci/floci:latest
    ports: ["4566:4566"]
    volumes:
      - ./data:/app/data
    environment:
      FLOCI_STORAGE_MODE: wal
      FLOCI_STORAGE_WAL_COMPACTION_INTERVAL_MS: 30000

Every mutation goes to an append-only log first, with periodic compaction. You get durability without paying the random-write cost of persistent mode.

Useful when you're stress-testing a service that writes a lot and high-volume DynamoDB, Kinesis-heavy pipelines, anything where persistent becomes the bottleneck but you still want crash-safety.

Per-service overrides

This is the part that doesn't exist anywhere else: set the global mode, then override only the services that need different behavior.

# docker-compose.yml
services:
  floci:
    image: floci/floci:latest
    ports: 
      - "4566:4566"
    volumes:
      - ./data:/app/data
    environment:
      FLOCI_STORAGE_MODE: memory                          # everything is ephemeral by default
      FLOCI_STORAGE_SERVICES_DYNAMODB_MODE: persistent    # except DynamoDB — keep that on disk
      FLOCI_STORAGE_SERVICES_S3_MODE: hybrid              # and S3 — keep buckets across restarts

Want fast tests but keep your seeded DynamoDB tables across restarts? Two env vars.

How this compares to LocalStack

LocalStack persistence is a single boolean (PERSISTENCE=1) that's locked behind the Pro tier. Beyond pricing, the design itself is different:

	LocalStack (Pro)	Floci
Cost	Paid tier	Free, MIT-licensed
Granularity	Global on/off	Four modes, per-service overrides
Write strategy	Snapshots (point-in-time)	Sync, async, or WAL — your choice
During snapshot	Service is locked, requests block	No locking, writes never pause
Cross-version	Snapshots may break across versions	Plain on-disk format
Implementation	Python `pickle` serialization	Native, format per service

The locking part is the one most people don't see coming. LocalStack's snapshot mechanism blocks requests to a service while it's being saved, which is fine for shutdown, but surprising mid-test. Floci never pauses writes; durability comes from the storage mode you picked, not from a freeze-and-dump.

A pattern that just works

For most teams, this covers 90% of what you need. CI:

services:
  floci:
    image: floci/floci:latest
    ports:
      - "4566:4566"
    environment:
      FLOCI_STORAGE_MODE: memory

Local development:

services:
  floci:
    image: floci/floci:latest
    ports: 
      - "4566:4566"
    volumes:
      - ./data:/app/data
    environment:
      FLOCI_STORAGE_MODE: hybrid

No auth token, no Pro tier, no surprise locking.

That's the point. Persistence isn't an enterprise feature, it's a basic developer ergonomic. Floci ships it that way.

🔗 github.com/floci-io/floci · 📚 Storage docs · 💬 floci.slack.com

Floci

Hector Ventura — Thu, 30 Apr 2026 00:13:46 +0000

Meet Floci: a fast, free, no-strings AWS emulator (no auth token, no quotas)

Hector Ventura — Wed, 29 Apr 2026 18:58:35 +0000

If you write code against AWS, you've probably hit one of these in the last year:

LocalStack Community Edition sunset in March 2026. Auth tokens, frozen security updates, paid tiers for the things that used to be free.
Spinning up real AWS for local dev or CI is slow, expensive, and risky.
Mock libraries lie to you until production day.

I started Floci to fix this. It's a single Docker image, MIT-licensed, no account, no telemetry, no feature gates. Pull and go.

TL;DR: docker run -p 4566:4566 floci/floci:latest and you have 40+ AWS services on http://localhost:4566. Same port and SDK calls as LocalStack. Switch by changing one env var.

🔗 GitHub: github.com/floci-io/floci
🔗 Docs: floci.io/floci

Why I built it

I was tired of three things:

Hidden costs. Free emulators that "encourage" you toward a paid tier the moment your team grows past 1.
Slow startup. Booting an emulator that takes 3+ seconds for every CI job multiplies into hours of waste per week.
Mock-only fidelity. Some services (Lambda, RDS, ElastiCache, Athena, EKS) need a real engine, not a JSON shim that pretends.

Floci is what I wished existed.

What makes Floci different

1. It's actually fast

Floci is built on Quarkus + GraalVM native image. No JVM warmup, no Python interpreter startup.

	Floci	LocalStack
Cold start	~24 ms	~3,300 ms
Idle memory	~13 MiB	~143 MiB
Image size	~90 MB	~2 GB

That gap is why Floci is comfortable on your smallest CI runner. A test that spins up a fresh emulator per job suddenly stops being painful.

2. Real Docker where it matters

Mock-only emulators are fine until your code starts depending on the real engine's behavior. Floci spins up real Docker containers for the services where wire protocols and execution semantics matter:

Lambda: real container per function, warm pool, aliases, Function URLs, SQS/Kinesis/DDB Streams event source mappings
RDS: actual PostgreSQL and MySQL containers with JDBC wire protocol proxying
ElastiCache: real Redis/Valkey with RESP proxying and IAM/SigV4 token validation
MSK: real Apache Kafka clusters
OpenSearch / EKS / ECS: real engines and orchestrators where applicable

This is the architecture from day one, not a feature flag, not a paid add-on.

3. Genuinely free and open

MIT licensed. Fork it, embed it, ship it inside your product. No "community edition sunset" coming.
No auth token. Ever.
No telemetry. Floci doesn't phone home.
No CI quota. Run 100,000 jobs a day if you want.
No feature gates. Every supported service is available to everyone.

4. Wire-compatible with the real AWS SDKs

Floci is validated by 1,850+ automated compatibility tests running across:

AWS SDK for Java v2
AWS SDK for JavaScript v3
boto3 (Python)
AWS CLI v2
AWS SDK for Go v2
AWS SDK for Rust
Terraform / OpenTofu / AWS CDK

The principle: the SDK source is the contract. If the official SDK can't tell Floci apart from AWS at the wire level, the test passes. If it can, that's a bug.

5. Drop-in for LocalStack users

Same default port (4566). Same wire protocols. Same SDK endpoint override. Migration is one env var:

- AWS_ENDPOINT_URL=http://localstack:4566
+ AWS_ENDPOINT_URL=http://floci:4566

That's it. Your application code, your IaC, your tests, all unchanged.

The 30-second tour

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

docker compose up -d

# Overwrite the aws-cli default URL endpoint
export AWS_ENDPOINT_URL="http://localhost:4566"

aws s3 mb s3://my-bucket
aws sqs create-queue --queue-name my-queue
aws dynamodb list-tables

In Java with the AWS SDK v2:

S3Client s3 = S3Client.builder()
    .endpointOverride(URI.create("http://localhost:4566"))
    .region(Region.US_EAST_1)
    .credentialsProvider(StaticCredentialsProvider.create(
        AwsBasicCredentials.create("test", "test")))
    .forcePathStyle(true)
    .build();

Done.

Testcontainers integration (it just works)
If you write JUnit/Spring Boot tests, there's an official Testcontainers module on Maven Central. No manual GenericContainer setup, no port juggling.

<dependency>
    <groupId>io.floci</groupId>
    <artifactId>testcontainers-floci</artifactId>
    <version>2.1.0</version>
    <scope>test</scope>
</dependency>

Then in your test:

@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();

        s3.createBucket(b -> b.bucket("my-bucket"));
    }
}

There's also spring-boot-testcontainers-floci for Spring Boot users. auto-configures Spring Cloud AWS to point at the container, zero boilerplate.
Module page: testcontainers.com/modules/floci

What's supported today

40+ services and growing. The big ones: S3, SQS, SNS, DynamoDB (+ Streams), Lambda, API Gateway v1 & v2, Cognito, KMS, Secrets Manager, IAM, STS, Step Functions, CloudFormation, EventBridge (+ Scheduler), CloudWatch Logs/Metrics, Kinesis, ElastiCache (Redis/Valkey), RDS (PostgreSQL/MySQL), ECS, EC2, OpenSearch, EKS, MSK, Glue, Athena, Data Firehose, ACM, AppConfig, Bedrock Runtime, SES/SES v2, SSM Parameter Store, etc.

Full per-service operation list: floci.io/floci/services

Where it's heading

EC2 with real Docker-backed compute (alpha)
Quarkus DevServices integration for Java devs
A per-language, per-service compatibility status dashboard

If any of that interests you or if a service you need isn't there yet, I'd love your input. Floci already has a great roster of contributors fixing real bugs and adding real services. There's room for more.

How to help

If Floci sounds useful:

⭐ Star the repo: github.com/floci-io/floci. It genuinely helps surface the project to other devs in the same boat
💬 Join Slack: community workspace at floci.slack.com. Questions, feedback, and weird edge cases all welcome
🐛 Open an issue: found a wire-level mismatch with the real AWS SDK? That's exactly the kind of bug I want to know about
🤝 Contribute: good first issues are labeled, and PRs that add a missing API operation are very welcome

Thanks for reading and if you give Floci a try, let me know what works and what doesn't. The whole point is to be the emulator developers actually want to use.