Floci: A Local AWS Emulator That Skips the Account and the Auth Token
Floci emulates selected AWS services on a local machine so cloud applications can be developed and tested without a remote account.
At a glance
- What is it?
- Floci emulates 83 AWS services on localhost with a Docker image around 90 MB, a native binary around 40 MB, and a startup time near 24 ms. It targets developers and CI pipelines that want AWS-shaped behavior without a cloud account.
- Who is it for?
- Adopt Floci if you need a free, token-free local AWS emulator for development, testing, or CI, especially if you rely on services like API Gateway v2, Cognito, or container-backed workloads that LocalStack Community lacks. Skip it if you require production-grade fidelity for every service, because the README admits that some services are stateless and shallow, and the project is young with a single primary maintainer.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Floci Actually Solves
Floci solves the problem of developing and testing AWS applications without a cloud account. The README is explicit: no account, no auth token, no feature gates. That is a direct response to LocalStack Community's sunset in March 2026, which the project cites as requiring auth tokens and freezing security updates. Floci positions itself as the no-strings-attached alternative. The target audience is clear: developers, CI pipelines, and anyone using AWS SDKs, CLI, Terraform, CDK, OpenTofu, or test suites. The core value is drop-in compatibility. You point your existing tools at http://localhost:4566 and keep your workflows. The project claims 83 AWS services, which is broad, but the README also shows that not all services are equal. Some are stateless, some are stateful, and some use real Docker execution. That distinction matters for anyone evaluating fidelity.
How Floci Works: Router, Stateless, Stateful, and Docker
The architecture diagram in the README shows a client (AWS SDK or CLI) hitting an HTTP Router built on JAX-RS and Vert.x, listening on port 4566. The router dispatches to two groups. Stateless services include SSM, SQS, SNS, IAM, STS, KMS, Secrets Manager, SES, Cognito, Kinesis, EventBridge, Scheduler, AppConfig, CloudWatch, Step Functions, CloudFormation, ACM, Config, CloudTrail, API Gateway, AppSync, ELB v2, and more. Stateful services are not fully listed in the truncated README, but the feature list points to Lambda, RDS, Neptune, ElastiCache, MSK, ECS, EC2, EKS, OpenSearch, CodeBuild, and Managed Service for Apache Flink using real Docker-backed execution instead of shallow mocks. That is a key design choice. For services where behavior matters, Floci spins up actual containers. For stateless ones, it likely simulates responses in memory. The README also mentions configurable persistence: in-memory, persistent, hybrid, and write-ahead log storage. That gives you control over durability, but the trade-off is that you must understand which mode fits your test scenarios.
Running Floci: CLI, Docker Compose, and Environment Variables
The quick start shows two paths. The fastest is the official CLI, floci-cli. You run floci start, then eval $(floci env) to export AWS environment variables, and then use standard AWS tools. The README gives a concrete example: aws s3 mb s3://my-bucket, then aws dynamodb create-table with a partition key and billing mode PAY_PER_REQUEST. For Docker Compose, you create a compose.yaml with the image floci/floci:latest and expose port 4566. After docker compose up, you export AWS_ENDPOINT_URL=http://localhost:4566, AWS_DEFAULT_REGION=us-east-1, and credentials set to test. The README notes that any non-empty credentials work unless you enable stricter service-specific auth checks. That is a practical detail for CI, but it also means that out of the box, Floci does not validate credentials. That is fine for local testing, but it can mask permission bugs that would surface in a real AWS account.
The LocalStack Comparison: What the Numbers Say
The README includes a comparison table between Floci and LocalStack Community. Floci claims a startup time of about 24 ms versus LocalStack's 3.3 seconds, idle memory around 13 MiB versus 143 MiB, and a Docker image size of about 90 MB versus 1.0 GB. Those numbers come from the project's own documentation, so treat them as vendor claims. The functional differences are more concrete. Floci supports API Gateway v2 and HTTP API, Cognito, and real Docker for RDS, ElastiCache, MSK, Neptune, DocumentDB, ECS, EC2, EKS, and CodeBuild. LocalStack Community does not, according to the table. The license difference is also notable: Floci is MIT, while LocalStack Community is restricted. The table is a direct pitch for migration, and the README includes a migration section for users of the old hectorvent/floci image, telling them to switch to floci/floci:latest because the old repository no longer receives updates. That is a practical warning, but it also highlights that Floci itself is a fork or successor with a history of image name changes.
Real Docker Where It Matters, But Not Everywhere
The README says Lambda, RDS, Neptune, ElastiCache, MSK, ECS, EC2, EKS, OpenSearch, CodeBuild, and Managed Service for Apache Flink use real Docker-backed execution. That is a strong fidelity claim. For a developer testing a Lambda function, running the actual Lambda runtime in a container is far more realistic than a mock that parses JSON. For RDS, spinning up a real database container means SQL semantics, indexing, and constraints behave like the real thing. But the README also lists many stateless services. Stateless services like IAM or STS are often simple to emulate because their responses are well-defined. However, stateless emulation can miss edge cases, such as IAM policy evaluation or STS token expiration. The README does not specify which services are stateless versus stateful beyond the categories in the architecture diagram. That means you cannot assume every service has the same level of fidelity. If your application depends on a service in the stateless list, you should test it explicitly against Floci before trusting it in a CI pipeline.
Limitations and When Floci Is the Wrong Tool
The most obvious limitation is that Floci is not AWS. Any emulator, no matter how broad, will have gaps. The README does not claim full parity with AWS. It says 'AWS-shaped services.' That phrasing is honest but also a warning. If you need to test behavior that depends on exact AWS semantics, such as IAM policy evaluation, CloudWatch alarm state transitions, or S3 consistency guarantees, Floci may not match. Another limitation is the persistence configuration. The README offers four modes, but it does not explain the trade-offs in detail. If you choose in-memory, data is lost on restart. That is fine for unit tests but wrong for long-running local development. The hybrid and write-ahead log modes likely add overhead. The README also notes that credentials can be any non-empty values unless you enable stricter auth checks. That means Floci is not a tool for testing authentication or authorization logic. It is a tool for testing application logic that calls AWS APIs. If your project's main risk is security policy misconfiguration, Floci will not help you find those bugs.
Maintenance and Upgrade Cost
The repository shows recent releases: 1.7.0 on 2026-08-18, 1.6.0 on 2026-08-06, and 1.5.34 on 2026-07-29. That is a rapid cadence, roughly weekly. The README mentions a migration from hectorvent/floci to floci/floci, which means existing users must update their image names. The project is under the floci-io organization, and the homepage is floci.io. The license is MIT, which is permissive. The README claims security updates are not frozen, unlike LocalStack Community. However, the project is young. The first release in the visible history is 1.5.34, and the latest is 1.7.0. That suggests active development, but it also means the API surface may change. If you adopt Floci, you should pin the image version in your compose file or CI configuration, and test upgrades in a staging environment before rolling out. The CLI tool is separate, floci-cli, so you need to track two repositories for updates.
Editorial conclusion
Adopt Floci if you need a free, token-free local AWS emulator for development, testing, or CI, especially if you rely on services like API Gateway v2, Cognito, or container-backed workloads that LocalStack Community lacks. Skip it if you require production-grade fidelity for every service, because the README admits that some services are stateless and shallow, and the project is young with a single primary maintainer. Before committing, verify that the specific AWS services you use are in the supported list, test your SDK or IaC workflows against the emulator, and check the persistence mode (in-memory, persistent, hybrid, or write-ahead log) that matches your durability needs. The project's MIT license and active release cadence (1.5.34 to 1.7.0 in under a month) suggest low licensing friction, but you should confirm the maintenance pace after the LocalStack Community sunset.
Community notes