Answer in brief: Floci is a free, MIT-licensed local AWS emulator written in Java that exposes AWS-shaped services on localhost:4566. It needs no AWS account, auth token, or paid feature gates. The maintainers’ 1.7.0 release (August 18, 2026) claims 73 emulated services, including Docker-backed Lambda, RDS, ECS, EC2, EKS, and MSK workloads. This is a source and documentation review as of August 24, 2026, not a runtime test. Floci is worth evaluating for local development and CI, but the project is young and several services are documented stubs or in-process approximations. Verify each service your team actually uses against its own workloads before standardizing on it.

key facts at a glance

what floci is and why it exists

Floci is an open-source local AWS emulator. According to the repository README, you point existing AWS SDKs, the AWS CLI, Terraform, CDK, OpenTofu, or test suites at http://localhost:4566 and keep your usual workflows. The operational pitch is that it needs no AWS account, auth token, or feature gates: just docker compose up or the official CLI’s floci start.

The maintainers position it as an alternative to LocalStack, whose community edition the LocalStack blog says sunset in March 2026 and which the README describes as now requiring auth tokens and frozen security updates. The README’s comparison table also claims roughly 24 ms startup time, 13 MiB idle memory, a 90 MB Docker image, and a 40 MB native binary. Treat those figures as maintainer claims, not independently verified results.

Architecture matters here. The README splits services into in-process stateless services (SQS, SNS, IAM, STS, API Gateway, EventBridge, CloudFormation), in-process stateful services (S3, DynamoDB), and Docker-backed services that run real software (Lambda, RDS, ElastiCache, MSK, ECS, EC2, EKS, OpenSearch, CodeBuild, and Managed Flink). Emulated therefore covers a range: some services are real engines in containers, some are in-process implementations, and some are stubs.

what 1.7.0 changes for operators

The 1.7.0 release notes describe the release as a maturity-and-breadth update. For someone evaluating the project, the operator-relevant changes are:

• Nine new services: Bedrock AgentCore, Lambda MicroVMs, CloudHSM v2, GuardDuty, SWF, S3 Tables, Managed Service for Apache Flink, Application Auto Scaling, and EC2 transit gateways.
• CloudFront serves real content: the maintainers say distributions now serve requests from S3 and custom origins, including signed private content, instead of configuration-only emulation.
• EKS IRSA with a real OIDC issuer: the release notes say IAM Roles for Service Accounts now works locally with JWT validation.
• CloudFormation growth: eleven new resource types, nested stack deletion, DeletionPolicy handling, SAM HttpApi expansion, and resource-level conditions.
• IAM managed-policy catalog: the release notes say the full AWS-managed policy catalog is now seeded, closing a common CDK and Terraform attachment gap.
• Cognito refresh-token hardening: three coordinated fixes for token expiry, HMAC signing, and rejection of invalid refresh tokens.
• Multi-account isolation: DynamoDB and S3 storage are now isolated per account, on top of earlier cross-account assumed-role routing.

These are the maintainers’ claims from the 1.7.0 release notes. They indicate where fidelity improved, not a guarantee for any specific workload.

who should consider floci

Floci fits teams that already build against AWS APIs and want a local or CI-resident stand-in. Realistic candidates include:

• Teams on LocalStack Community who lost the free update path and need a migration target.
• Teams working mostly with core services (S3, SQS, SNS, DynamoDB, Lambda, API Gateway, Step Functions, CloudFormation), where the emulator is most mature.
• Teams using Testcontainers in Java, Node.js, or Python, where the README lists Floci modules (Java 1.4.0, Node 0.1.0, Python 0.1.1) for isolated per-test instances.
• CI pipelines that want AWS-shaped tests without provisioning cloud resources for every run.

The inverse is also clear. If your workload depends on a stub (Bedrock Runtime, Textract, Transcribe, cost APIs, or FIS fault injection), the README describes those as dummy responses or control-plane simulations, so Floci will not validate that behavior.

deployment concerns and what to check first

Before standardizing on Floci, operators should check five things specific to this project:

1. Service fidelity per workload. The README’s service table is useful precisely because it distinguishes real implementations from approximations: Bedrock Runtime and AgentCore return dummy or canned responses, Textract and Transcribe complete jobs with no real processing, Cost Explorer synthesizes cost from Floci state, and Application Auto Scaling policies are stored but inert. Map every API operation you call against the table before trusting a test result.
2. Docker socket access. The documented run command mounts /var/run/docker.sock and runs as root (-u root). That is required for container-backed services, but it also means the Floci process can control the Docker engine. On a shared laptop, CI runner, or server, decide who may start Floci and what those containers can reach.
3. Image pinning and release cadence. The docs show floci/floci:latest, yet the project published five releases between July 11 and August 18, 2026 (1.5.32 through 1.7.0). For reproducible CI, pin a tag and update deliberately.
4. Persistence mode. Storage can be memory, persistent, hybrid, or wal. In memory mode, data is lost when the container stops, which is fine for CI but wrong if developers expect state to survive restarts.
5. The image-name migration. The README says the old hectorvent/floci image no longer receives updates; compose files must move to floci/floci. Any existing compose setup should confirm which image it actually runs.

Multi-account behavior also deserves a look: a 12-digit access key is treated as the account ID, anything else falls back to FLOCI_DEFAULT_ACCOUNT_ID (default 000000000000), and the README says STS temporary credentials resolve to the assumed role’s account. Cross-account tests only mean what they should if your test code uses realistic key shapes.

maintenance signals to watch

The project is active but young. The repository was created February 18, 2026, and last pushed to August 23, 2026, about six months old at review time, with 21,462 stars and 2,249 forks as a snapshot. The signals cut both ways:

• Rapid, regular releases: 1.5.32 (July 11), 1.5.33 (July 15), 1.5.34 (July 29), 1.6.0 (August 6), 1.7.0 (August 18). Momentum and a working release pipeline, but also a moving target.
• Open issues: 161 open issues at review time. Normal for a popular project, but check the tracker for your specific services, especially newly added ones like GuardDuty or S3 Tables.
• Supply-chain practices: the 1.5.34 release notes say published images now include provenance and SBOM attestations, a positive signal for teams that verify what they pull.
• Concentrated release ownership: all listed releases are authored by hectorvent under the floci-io organization. Recent release notes welcome first-time contributors, but release responsibility remains concentrated, which matters when you plan around responsiveness.

honest limitations

Floci is an emulator, and the README itself documents where emulation is shallow:

• Not a substitute for real AWS verification. An emulator can validate your code against the API contract; it cannot validate real IAM policy effects, eventual consistency, network behavior, or service limits.
• Docker-backed services are still approximations. A local PostgreSQL, Redpanda, or k3s is closer to AWS than a mock, but it is a local engine, not an AWS-managed service.
• Fresh code paths carry risk. Several 1.7.0 additions (GuardDuty, S3 Tables, Lambda MicroVMs, CloudHSM v2) landed in a single release. Broad release notes do not prove deep conformance.
• Performance claims are unverified here. Startup, memory, and image-size figures come from the README comparison table, and this review performed no benchmarks.

alternatives and evaluation questions

The alternative named in the repository’s own materials is LocalStack. The README presents Floci as a response to LocalStack Community’s March 2026 sunset and its auth-token requirement, and it includes a migration section; the shared port 4566 and AWS wire protocol make a side-by-side comparison practical. Verify the sunset and token claims against the LocalStack blog yourself before making a decision based on them.

Before committing, answer these questions with your own codebase:

• Which AWS services and operations does your application actually call, and does the Floci service table implement them for real rather than as stubs?
• Can your CI cache the Docker images Floci pulls, or will every pipeline download PostgreSQL, k3s, Redpanda, and friends?
• Who can reach Floci’s endpoint and the mounted Docker socket in your development and CI environments?
• Do you need persistence across restarts, and which storage mode fits each workflow?
• Do your tests depend on AWS error classes or status codes that an emulator may approximate differently?
• Where is your real-AWS smoke test, and does it run regardless of what the emulator passes locally?

verdict

Floci deserves serious evaluation from teams that need free local AWS emulation and are losing LocalStack Community’s free path. The strongest fit is a team built on S3, DynamoDB, SQS, Lambda, API Gateway, and CloudFormation that already uses Docker and wants AWS-shaped tests in CI without cloud spend. The weakest fit is a team needing fidelity from stubbed services, or one that cannot tolerate a root process with Docker socket access on shared infrastructure.

The recommendation is conditional: run a small proof-of-concept against your own integration suite, pin a release, review open issues for the services you depend on, and keep a real-AWS smoke test as the final gate. The project’s velocity is a positive sign, but velocity in an emulator raises the importance of pinning and validation rather than lowering it.

sources

• floci-io/floci repository: README, service table, and metadata, observed August 24, 2026
• Floci 1.7.0 release notes
• Floci documentation
• LocalStack: the road ahead, referenced by the README for the Community edition sunset

If this review matches your situation (a team migrating off LocalStack, a compose file still pointing at the old hectorvent/floci image, or a CI pipeline that needs AWS-shaped services without drifting versions), I can handle that as a migration and maintenance job: pin and containerize Floci for your stack, wire SDK, CLI, Terraform, or CDK flows to it, audit service-by-service fidelity against the release notes and open issues, and keep the local AWS environment current instead of quietly breaking. That is the kind of ongoing technical ownership I provide for small teams without a full-time DevOps person.