Floci and Local AWS Emulation: A Tool I’m Curious to Try
After using LocalStack for years and publishing the first four parts of my local AWS series, Floci caught my eye: MIT licensed, no account required, and built around the same localhost:4566 workflow.
I’ve been using LocalStack for a long time. Long enough that I started a full “Run AWS on Your Laptop” series around it. Part 0 through Part 4 are already live, and the first hands-on build is Part 1 - S3 Photo Uploader with Presigned URLs.
That series came from a simple itch: I wanted to build AWS-shaped projects without turning every experiment into a billable cloud exercise. S3 uploads, DynamoDB tables, Lambda handlers, queues, schedules, API Gateway routes - the usual backend building blocks, but running on my own machine.
LocalStack has been great for that. I still think it has done more than almost any tool to make AWS feel learnable outside the AWS console.
Then I came across Floci.
And yes, I’m curious.
The interesting bit is the low-friction model
Floci describes itself as a free, open-source local AWS emulator. The project README says it is MIT licensed, has no account requirement, and has no advertised feature gates.
That last part matters more than it sounds.
One of the reasons LocalStack became so useful for me was the loop:
docker compose up
export AWS_ENDPOINT_URL=http://localhost:4566
aws s3 mb s3://my-bucket
Fast. Local. Boring in the best way.
Floci appears to keep that same mental model. Its quick start exposes services through http://localhost:4566, and the README says credentials can be placeholder values, just like the LocalStack workflow most of us already know.
What Floci claims today
The Floci README currently lists some eye-catching numbers: around 13 MiB idle memory, around 24 ms startup time, and around a 90 MB container image.
I’m not treating those as my own test results yet. I haven’t run a proper comparison on my machine. But as project claims, they’re interesting enough to make me want to test it.
The service list is broad too. Floci currently advertises support for AWS-shaped APIs across storage, compute, messaging, identity, databases, API Gateway, EventBridge, Step Functions, CloudFormation, CodeBuild, EKS, EC2, MSK, RDS, ElastiCache, Athena, and more.
The part that made me pause is how it handles some services.
For several heavier pieces, Floci says it uses real backing containers rather than plain in-memory approximations:
- Lambda runs with AWS public ECR runtime images
- RDS can use PostgreSQL, MySQL, or MariaDB containers
- ElastiCache can use Redis or Valkey
- MSK uses Redpanda
- EKS can run through k3s
- EC2-style instances map to Linux containers with SSH, UserData, and metadata support
- CodeBuild executes buildspec phases in a container
That doesn’t make it “the same as AWS”. Nothing local is the same as AWS. IAM, edge cases, service timing, API gaps, and weird integrations always need care.
But it does make Floci worth a look.
The LocalStack shift still stings a bit
Here’s where the timing gets interesting.
LocalStack announced that from March 2026, LocalStack for AWS would move to a unified, account-based delivery model. The old Community image can still be pinned to older versions, but LocalStack’s own roadmap post says the Community Edition will not receive future patches, including security patches.
The replacement is the free Hobby plan for non-commercial use, with paid plans for commercial and team use. The current LocalStack pricing page lays out those plan lines.
I understand the business side. AWS emulation is hard to build and harder to maintain.
Still, as someone who has used LocalStack for years, I can’t pretend that shift feels good. The old community flow was very low friction: pull the image, run it, point your SDK at localhost:4566, and keep building.
Adding accounts, auth tokens, and plan boundaries changes the feel of the tool.
That matters for side projects. It matters for demos. It matters for CI experiments. It matters for people learning AWS on a weekend without wanting another SaaS login in the middle of the path.
I’m not saying LocalStack is bad now. I’m still using it, and my current series is built around it. I’m saying the trade-off has changed, and developers notice those changes.
So where does Floci fit?
Right now, I see Floci less as a proven replacement and more as a project worth testing.
The promise is appealing:
- local AWS-style APIs
localhost:4566- no account
- no token
- MIT license
- broad service coverage
- real containers behind selected services
That’s a strong pitch for learning, experiments, throwaway prototypes, and local integration tests.
The real test is boring, though: does it behave well when real application code hits it?
That’s what I want to find out.
I’m planning to try Floci against some examples from my LocalStack series: the S3 presigned upload flow, the DynamoDB shortener, and the Lambda thumbnail pipeline. Those are small enough to port quickly, but real enough to expose gaps.
If it works, great. If it doesn’t, that’s useful too.
Competition is good for local cloud development
This is the part I keep coming back to.
LocalStack pushed local AWS development forward. A lot. It made the idea normal.
But a space like this gets healthier when there is more than one serious option. Developers get better tools. Projects get sharper. Pricing pressure stays real. Open-source users have somewhere to go when a product changes shape.
So no, I’m not declaring Floci the new default after reading a README.
I am saying this: a lightweight, MIT-licensed, no-account AWS emulator is exactly the kind of thing I want to see more of.
And I’m going to try it.
If you’ve already tested Floci in a real workflow, I’d love to know how close it felt.
Useful links
