Floci: Real AWS on Your Laptop, and What LocalStack's Paywall Left Behind

0:00The video opens with a story: a small startup builds the leanest possible serverless backend — one function receives an image, one storage bucket holds it — and it works, free, inside AWS's free tier. Then a change makes the bucket's events trigger the same function that writes to the bucket. Infinite loop. 0:24One month later the bill has gone from about a thousand dollars to $47,283.

Whether that specific invoice is real or illustrative, the mechanism is the most ordinary failure mode in cloud engineering: the bill is a function of loops, and a loop you can't see is a loop you can't stop. The presenter's own diagnosis is sharper than "AWS is expensive": 0:34it isn't the cloud, it's the ease of a seemingly endless pool of resources you can spin up at any time. That framing is why a local emulator is interesting — not as a toy, but as a blast radius.

The $47k story, and the case for a local cloud

0:44The alternative the video proposes: keep production real, but run the tests — and, in its words, your irresponsible agents — against infrastructure that costs nothing because it lives on your machine. Databases, clusters, DNS, CDNs, 1:01every service you'd touch on AWS, Azure or Google Cloud, at zero cost and zero blast radius.

The pitch is not "reproduce AWS". It's "give the loop somewhere harmless to happen": the same SDK calls, the same CLI, the same Terraform, pointed at localhost. If the loop runs wild at home, you delete a container.

What changed at LocalStack

1:15The video frames this as a market opening: LocalStack, the incumbent local-AWS emulator, "started moving more and more services under a pay wall, tightening its license". That deserves precision, because it is the load-bearing claim behind the whole recommendation — and it checks out, in a more specific form than "paywall".

LocalStack's own announcement, "The Road Ahead for LocalStack" (published 18 Dec 2025, updated 17 Mar 2026), says that from March 2026 the Community and Pro editions are replaced by one unified version that requires an account. The Community image stops receiving regular updates and security patches; the source stays on GitHub but the repo is marked inactive. A free plan remains for individual engineers, but the post's update states the free tier is intended for non-commercial use. Their stated reason: an anonymous pull-only user base they can't engage with.

1:30So: not exactly a wall around the software you already have, but the end of the free ride as an unattended Docker image in CI. For anyone whose pipelines do docker pull localstack/localstack and never look at it again, that is a breaking change — and precisely the gap a free MIT alternative can walk into.

What Floci is

1:45Floci ("any cloud, locally") is a free, MIT-licensed local cloud emulator family. 2:02It went public in February 2026, written by Hector Ventura (Texas — his GitHub bio reads "Creator of Floci"); the org repo now has 30,892 stars, 3,367 forks, 199 open issues, and it is written in Java. Its README promises "no account, no auth token, no feature gates", and its name is a joke on floccus, the popcorn-shaped cloud.

2:08"Supports all major clouds" needs one clarification the video itself later makes: it is not one binary that speaks four clouds. It is a family of four sibling emulators, each its own repo, image and port, driven by one CLI:

The CLI is a separate MIT project, floci-cli. The AWS emulator's documentation lists about 135 service pages, from S3, DynamoDB and SQS up through EKS, RDS, Neptune, DocumentDB, Bedrock Runtime and Cost and Usage Reports.

The numbers, checked

2:15The speed claims are the most quotable part of the video, and they come from one table in the Floci README comparing itself with LocalStack's Community edition — so they are vendor benchmarks, not a neutral third-party test. Here is that table, with the numbers independently re-checked where a public source exists:

2:28The video states the image is 19 MB, "more than 10 times smaller" than LocalStack's gigabyte. The ratio is roughly right against the README's unpacked figure, but the 19 MB number isn't supported by anything I can find: the published image is 94.6 MB on Docker Hub, the console sidecar is 47 MB, and the CLI binaries are 32–44 MB. Treat "small" as confirmed, "19 MB" as not.

2:31The honest summary of the performance story: a container that starts in tens of milliseconds and idles at ~13 MiB is a different category of thing from a multi-second, hundred-megabyte warm-up — which matters in CI, where the emulator's startup is pure overhead multiplied by every job. The exact multiples above are the vendor's own measurement of its own advantage.

First run: download, start, export, go

3:00Install and start, then point your tools at it. 3:12Under the hood floci start runs Docker Compose, pulling layers and bringing up one container; more containers appear on demand when a service needs one.

3:33The first stumble is genuinely instructive. The video tries aws s3 ls and gets a missing-credentials error — from a tool that advertised "no credentials needed". Both are true: Floci needs no real credentials, but the AWS CLI insists on something being set. 3:38The fix is the CLI's eval $(floci env), which exports the endpoint, fake keys and region (us-east-1 by default, overridable with floci env --region). 3:56The presenter then hits a wrong default region and fixes it by hand — a reminder that these are environment variables, and environment variables are where local emulation always gets fiddly.

4:04After that: get-caller-identity answers like real STS, aws s3 mb s3://floci-bucket creates a bucket, an object goes in and comes back. 4:21That is the whole demo loop — the same commands you'd run against us-east-1, minus the bill.

5:27(The paid Firecrawl segment runs here, 4:27–5:39: search API, a crawling path, and "Alexandria", described as an index of 100M+ sources and 400+ data providers with plug-ins for popular agents. Sponsor copy, not a tested claim.)

Where it's real Docker, and where it's a mock

5:41A useful detail from inside the container: state lives in JSON index files under /app/data, 5:52so if you want a persistent local cloud, mount that path as a volume. The project documents four storage modes — memory, persistent, hybrid and write-ahead log.

6:11The interesting axis is fidelity, and the README is unusually explicit about it. A large set of services are answered in-process (S3, DynamoDB, SQS, SNS, KMS, IAM, Secrets Manager, SSM, Kinesis, CloudWatch Logs and Metrics, EventBridge, API Gateway, Cognito, Step Functions…), while the ones where mocking would be pointless run real containers:

6:28The demo does what a local AWS should be judged on: it creates an EKS cluster, authenticates to it with the AWS CLI, deploys pods, reads logs, scales a deployment — 6:51and behind the scenes Floci starts ECR and then EKS as separate containers as they're needed. 7:08SQS behaves the same way: create a queue, send a message, receive it, and the responses are shaped like the real ones.

Console, Terraform, and the bit nobody demos

7:30Floci ships a web console for the resources in your local cloud, and — a nice touch — it lives on the emulator's own port: http://localhost:4566/_floci/ui. The first request pulls a console sidecar image, starts it on Floci's Docker network, hands it the emulator's address and the standard AWS environment, polls its health endpoint, then redirects you. The sidecar itself listens on 4500, and the console is swappable — any image implementing the documented "console contract" works.

7:39The service list is the real argument here: Athena, Config, Cognito, Cost and Usage Reports, SSM, SSO with Google connectors, KMS, Secrets Manager, CloudWatch, DynamoDB. 8:12The presenter sets a secret in Secrets Manager, watches KMS encrypt and decrypt it, then tours a networking panel that puts VPCs, subnets, gateways and route tables in one view — his aside that AWS should learn from this is fair, if partisan.

9:00The part that decides adoption for real teams is IaC: does Terraform work unchanged? Two settings do it — skip_credentials_validation (documented in the Terraform AWS provider for exactly this case) and per-service custom endpoints — after which terraform apply provisions instances against Floci, and describe-instances returns the same shape of response you'd get from the cloud. Floci's own docs go further than the video shows: a Terraform guide, and a migration page that translates LocalStack's environment variables (PERSISTENCE, LOCALSTACK_HOST, LAMBDA_DOCKER_NETWORK…) and even prints a LocalStack-style Ready. line so that Testcontainers' LocalStackContainer wait strategy keeps working.

One CLI, four clouds — with a seam

10:12The CLI is tree-shaped by cloud: floci or floci aws for AWS, and floci gcp, floci az, floci oci for the rest. 10:40floci stop, floci start, floci doctor (diagnose Docker, the socket, versions), floci services (list what's available), plus restart, status, logs, wait, reset and snapshot commands. 10:56Switching to GCP pulls a different image, floci-gcp.

11:23And here is the seam the video is honest about: switch the console to GCP without updating the endpoint environment and you get "runtime unavailable / disconnected". Point it at the right emulator and GKE, Cloud Run and the rest light up. 11:37Four emulators, four ports, four environments to keep straight — one CLI, but not one cloud.

Why this matters beyond DevOps

2:41The video's own pivot is the one that matters here: "perfect for your crazy agents". 11:50A coding agent in YOLO mode against a real cloud account is the $47k story with a faster loop: it can create a cluster, a NAT gateway, a DynamoDB table with provisioned throughput, and it will do it again tomorrow. Against localhost:4566, the worst case is a reset command.

What the video doesn't mention, and the repo makes obvious: the project is built for agents on purpose. floci-cli ships an agent skill (skills/floci/SKILL.md plus per-cloud references, Docker, CI/Testcontainers, namespaces and troubleshooting files) and a Claude Code plugin manifest, so an agent can be told the ports, the CLI tree and the known failure modes before it touches anything. That is the difference between "you can point an agent at it" and "an agent knows what to do with it".

Install or skip

Use it if you want AWS-shaped services locally without an account, if your CI pulls LocalStack Community and you'd rather not rebuild that on an account-based tier, if you deploy with Terraform and want apply to be free and repeatable, or if you are letting an autonomous agent do infrastructure work and want a blast radius of zero.

Be careful if you need fidelity rather than convenience: an emulator is a set of claims about how AWS behaves, and every in-process mock is a place where your code learns a slightly wrong lesson. Real-Docker services narrow that gap; the in-process ones don't. Also note the shape of the project: 199 open issues in eight months, Java, Docker required (Podman via DOCKER_HOST), and benchmarks measured by the vendor on its own advantage.

And a line worth keeping from the README itself: "always free" is a promise, not a license term. MIT protects the code you have today; it does not oblige anyone to keep developing it. LocalStack was the free, open local-AWS emulator once too.

📚 Sources & further reading

⏱ Timestamp index