Sometimes a developer just wants to test something. Not deploy it to the real cloud. Not wait for a bill. Not create yet another account. Not spend half the afternoon fixing tokens, permissions, and weird test environments. Just test the thing. That is where Floci comes in.

Floci is an open-source tool that lets developers run a local version of many AWS-style cloud services on their own machine. In plain English: it gives you a small fake AWS playground on your computer, so you can build and test software without constantly touching the real Amazon cloud. The project describes itself as a free local AWS emulator, and its GitHub page says it is designed to run without accounts or feature gates.

So what is Floci, really?

Imagine you are building an app that uses AWS services like S3, SQS, DynamoDB, Lambda, IAM, or CloudWatch.

Normally, to test all that properly, you might need to connect to AWS itself. That can be powerful, but it also brings baggage: credentials, permissions, costs, internet access, cleanup scripts, and the constant worry that a test might accidentally touch something real. Floci tries to move that work onto your own machine.

You point your AWS tools or code at Floci, usually on localhost:4566, and your app behaves as if it is talking to AWS. Under the bonnet, it is talking to Floci instead. The project says existing AWS CLI and SDK calls can be pointed at the local endpoint without changing the rest of the code.

Why developers may care

The big attraction is speed and control. A local test environment is usually faster than waiting for real cloud services. It is also cheaper, because you are not spinning up actual AWS resources every time you run a test. And it is safer, because a messy experiment stays inside your laptop or CI pipeline instead of landing in a real production account.

That makes Floci especially interesting for developers who write integration tests. These are the tests that check whether different parts of an app work together: queues, buckets, databases, functions, permissions, events, and all the boring but important plumbing. With a tool like Floci, a developer can test more of that plumbing locally before pushing code further down the line.

The LocalStack comparison

Floci is clearly positioning itself as an alternative to LocalStack, the better-known local AWS emulator. This matters because LocalStack changed its packaging in 2026. LocalStack announced that from March 2026 its AWS emulator would move to a single image model requiring an account and auth token for current releases, including CI usage. It also said regular updates and security patches would no longer be the focus for the old Community edition.

That created an opening for tools that keep the old simple idea alive: pull a container, run it locally, and get on with your day. Floci leans hard into that idea. Its message is basically: no account, no token, no artificial wall between the developer and the tool. That is probably the main reason people are paying attention to it.

What can it emulate?

Floci is not just a toy S3 clone. The project lists support for a wide range of AWS-style services, including S3, SQS, SNS, DynamoDB, Lambda, API Gateway, IAM, STS, Cognito, KMS, Kinesis, Secrets Manager, Step Functions, CloudFormation, EventBridge, CloudWatch, RDS, ElastiCache, MSK, ECS, EC2, EKS, OpenSearch, CodeBuild, CodeDeploy, Route53, Transfer Family, and more. The README currently says 46 AWS services are supported.

That does not mean every tiny corner of AWS behaves perfectly. No emulator can magically become the full AWS universe. But the coverage is broad enough to make Floci more than a quick experiment. For teams that rely on queues, buckets, serverless functions, databases, and event-driven workflows, this kind of local emulator can save a lot of time.

The clever bit: some services use real containers

One interesting design choice is that Floci does not pretend everything can be faked in memory. For some services, it uses real Docker containers. For example, the project says Lambda can run with real AWS runtime images, RDS can use real PostgreSQL or MySQL containers, MSK can use Redpanda for Kafka-style behaviour, EKS can run through k3s, and OpenSearch can run as an actual OpenSearch container.

That is important because some systems are too complex to fake well. A simple mock is fine when you only need a yes-or-no answer. But if you are testing how an app behaves with a database, a queue, a runtime, or a search engine, the details matter. The closer the local service behaves to the real thing, the fewer surprises you get later.

It is also built for CI

Floci looks useful not just on a developer laptop, but also inside automated test pipelines. If a project can start Floci during CI, run its tests, then throw everything away, that gives the team a repeatable test environment. No shared test AWS account full of old resources. No mystery buckets from six months ago. No “it works on my machine” theatre.

The default storage mode is memory-based, which means data disappears when the container stops. That is good for quick tests. But Floci also supports other storage modes, including persistent, hybrid, and write-ahead log options for cases where local state needs to survive restarts.

Who is Floci for?

Floci is mainly for developers, DevOps engineers, platform teams, and anyone building software that talks to AWS.

It is useful if you:

• build apps that depend on AWS services;
• want faster local tests;
• want fewer real cloud costs during development;
• need repeatable CI environments;
• dislike having local tools tied to accounts and tokens;
• want an open-source AWS-style emulator you can inspect and run yourself.

It is probably not for someone who just wants to host a website or store a few files. This is a developer tool. A good one, but still a developer tool.

The catch

There is always a catch. First, Floci is not AWS. It imitates AWS. That means you should still test important production behaviour against the real cloud before trusting it completely.

Second, some features need Docker access. The README shows Docker-backed services requiring access to the Docker socket. That is powerful, but it is also something you should treat carefully, especially on shared machines or locked-down environments.

Third, because this is a fast-moving open-source project, you should expect rough edges. AWS is enormous. Matching it perfectly is a brutal job. The right expectation is not “perfect clone of AWS forever.” The right expectation is “very useful local test environment that can remove a lot of friction.”

So, is Floci worth a look?

Floci feels like one of those tools that appears because developers are tired of unnecessary faff. The idea is simple: local cloud testing should be quick, free, and boring. Not boring in a bad way. Boring in the beautiful way that a kettle is boring. You switch it on, it works, and nobody needs a meeting.

For teams already using AWS-style services in development, Floci is worth a look. It may not replace every real cloud test, and it should not be treated as production AWS in disguise. But for everyday development, integration testing, and CI pipelines, it could be exactly the kind of practical little helper that saves hours without making a fuss.

In short: Floci is a local AWS playground for people who want to build, test, break things, reset everything, and move on with their lives.

Link: https://github.com/floci-io/floci