mrkeyoor.com_
Tue 01 Sept 17:41 UTC
Dev Toolsevaluationupdated 26 Aug 2026

floci review

Floci is a local AWS emulator for development, integration tests, and CI. It accepts familiar AWS SDK, CLI, Terraform, OpenTofu, and CDK requests on one local endpoint, then handles many services in-process or starts real Docker containers where a shallow mock would be misleading.

+601stars / 7d
Verdict

Our Floci CDK compatibility build finished in 11 seconds, but the package had no test target and npm audit found 1 high-severity vulnerability. Floci is the most interesting choice for teams leaving LocalStack Community and needing broad, token-free local AWS behavior. Adopt it service by service, because its 76-service headline mixes in-process emulation, real containers, stubs, and simulations with different fidelity.

We ran it

Lab card: what happened when we ran flociScreenshot of floci (floci.io/floci)
Install✓ · 18s18 packages · 222 MB
Build✓ · 11s
Testsn/ano test script
Known vulns10 critical · 1 high · 0 moderate · 0 low (npm audit)
Repo2854 files~651,122 lines of source · 30.2 MB · 13 CI workflows · Dockerfile · tests dir

Answers from our run

Does floci build from source?

Dependencies installed in 18 seconds (18 packages), and the build succeeded in 11 seconds. We cloned commit e4b101d into a clean Debian container with 3 CPUs and no project-specific setup.

Does floci have tests you can run?

Not through a standard command: the project exposes no test script or target that our harness could run.

Does floci have known vulnerabilities in its dependencies?

npm audit flagged 1 known advisory in the dependency tree at the time of our run.

Who should not use floci?

Teams that need exact AWS behavior across every operation: the README publishes service-level notes and labels several implementations as stubs, simulations, or stored-but-inert controls.

What are the alternatives to floci?

LocalStack, Moto, AWS SAM CLI. Our Floci CDK compatibility build finished in 11 seconds, but the package had no test target and npm audit found 1 high-severity vulnerability.

Setup4/5One local endpoint, though high-fidelity services need Docker access
Docs5/5Clear service matrix, migration, storage, SDK, and Docker notes
Community5/522,260 stars with an August 26 push and frequent releases
Maturity4/5Broad coverage, with fidelity varying by service and operation

Discussed on

  1. hnFloci: Light, fluffy, and always free – The AWS Local Emulator alternative3 points

Who it’s for

Teams replacing LocalStack Community while keeping its common port and endpoint pattern.
AWS application developers who want S3, DynamoDB, queues, events, identity, and infrastructure tests without a cloud account.
Test suites that benefit from isolated Floci instances through Java, Node.js, or Python Testcontainers modules.
Platform engineers willing to verify operation-level compatibility for the exact AWS APIs their stacks call.

Who it’s NOT for

Teams that need exact AWS behavior across every operation: the README publishes service-level notes and labels several implementations as stubs, simulations, or stored-but-inert controls.
Environments that cannot expose a Docker engine to the emulator: Lambda, RDS, EKS, ECS, OpenSearch, CodeBuild, and other higher-fidelity services use real Docker.
Security policies that forbid mounting /var/run/docker.sock into a root container: the documented Docker-backed setup does exactly that.
Buyers treating local success as proof of cloud behavior: emulation reduces feedback time but cannot reproduce AWS networking, IAM, quotas, or managed-service operation in full.
Projects requiring a test command in the CDK compatibility package: our measured subproject had no test script or target.

Setup reality

Our sandbox entered compatibility-tests/compat-cdk, installed 18 npm packages in 18 seconds, and used 222 MB on disk. Its build succeeded in 11 seconds. There was no test script or target, so tests were skipped. npm audit reported 1 known high-severity vulnerability, with 0 critical, 0 moderate, and 0 low findings.

The product quick start runs floci start or one Docker Compose service on port 4566. SDKs need a local endpoint, region, and non-empty placeholder credentials. Container-backed services also need the Docker socket; multi-container applications should set FLOCI_HOSTNAME so returned URLs resolve from the application container.

Our test method used commit e4b101d in an unprivileged Node 22 container with 3 CPUs, 8 GB of RAM, and no secrets. The measurement covers only the nested CDK compatibility project, not Floci's Java server or Docker image. The repository had 2,854 files, a Dockerfile, 13 CI workflows, and a tests directory.

Floci emulates 76 AWS services without an account or token

Floci presents one AWS-shaped endpoint at port 4566 and lets existing SDKs, the AWS CLI, Terraform, OpenTofu, and CDK talk to it. The pitch is direct: local cloud behavior without a cloud account, an auth token, or paid feature gates. Core services include S3, DynamoDB, SQS, SNS, Lambda, IAM, KMS, Cognito, EventBridge, Step Functions, and CloudFormation. The same repository reaches into databases, analytics, container platforms, billing, governance, and Bedrock APIs.

Breadth is only useful when its limits are visible, and Floci's README does a decent job here. Each service is described as in-process, Docker-backed, a stub, or a simulation. Bedrock Runtime returns dummy responses. Textract and Transcribe return canned or immediate results. Fault Injection Simulator models the control plane without disrupting other services. Application Auto Scaling stores some policies without applying them. A test can validate API wiring against those behaviors, but it cannot infer that AWS will act identically.

Real containers improve fidelity and increase privilege

Floci starts actual engines where wire protocols or runtime behavior matter. RDS uses PostgreSQL, MySQL, or MariaDB containers. ElastiCache uses Valkey, MSK uses Redpanda, DocumentDB uses MongoDB, and EKS uses k3s. Lambda runs AWS runtime images, while ECS starts the image supplied by the user. This is much more useful than returning canned JSON when an application must open a database connection, consume Kafka records, or execute a function.

The documented Docker route mounts /var/run/docker.sock and runs the Floci container as root. That gives the emulator broad control over the host Docker daemon. It may be acceptable on a developer laptop or disposable CI runner, yet it is a serious boundary in shared infrastructure. Real services also pull several upstream images and expose extra ports. Teams should isolate runners, pin image tags, restrict network exposure, and avoid putting production credentials anywhere near the local environment.

What happened when we ran it

Our sandbox measured the nested compatibility-tests/compat-cdk project at commit e4b101d, not the Java server or released Docker image. npm installed 18 packages in 18 seconds and occupied 222 MB. The package then built successfully in 11 seconds. The full repository contained 2,854 files and about 651,122 source lines, while the checkout used 30.2 MB. The container had 3 CPUs, 8 GB of RAM, Node 22, and no secrets.

There was no npm test script or target in that subproject, so our harness skipped tests. npm audit reported 1 known vulnerability, rated high severity, with 0 critical, 0 moderate, and 0 low findings. The repository itself has a tests directory and 13 CI workflow files, but those signals do not convert the skipped command into a pass. Teams using CDK should add a real deployment assertion around the stacks they expect Floci to accept.

LocalStack migration is easy until an operation differs

Floci deliberately accepts the familiar LocalStack port, credentials, health endpoint, init-script path, and ready-log shape. Its configuration translates several common LocalStack environment variables automatically. For a basic Compose setup, migration can be as small as replacing the image name. A compatibility image includes AWS CLI and boto3 for init scripts. That attention to surrounding tools is a strong reason to try Floci before rewriting a local test harness.

Compatibility still needs to be checked at operation level. The services page is the buying document, not the 76-service total. A project may need one uncommon S3 checksum path, a CloudFormation resource update, or a particular Cognito error. Floci's v1.7.0 notes list fixes for precisely these narrow behaviors across S3, Lambda, API Gateway, CloudWatch, Cognito, DynamoDB, and container cleanup. Replace the image in a branch, run the application's integration suite, and record any AWS call that diverges.

Storage modes cover CI and persistent development

The default memory mode loses state when the container stops, which is usually correct for isolated CI. Persistent mode flushes every write, hybrid mode keeps active data in memory and flushes periodically, and write-ahead logging records mutations before responding. Per-service overrides allow a team to retain an S3 or DynamoDB fixture while keeping disposable queues elsewhere. Multi-account isolation uses 12-digit access-key IDs as account IDs and routes temporary STS credentials to their assumed account.

These features make local scenarios richer than a single fake account. They also create state that can hide test dependencies. CI should prefer fresh memory-mode instances through Testcontainers, while long-lived developer environments may choose hybrid storage. Java, Node.js, and Python Testcontainers modules are listed as available; the Go module is described as in progress, so Go teams should not write plans around it yet. Any credentials should remain obvious placeholders unless a service-specific auth check requires something else.

Active releases support a cautious service-by-service rollout

GitHub showed 22,260 stars, 184 open issues and pull requests, and a last push on August 26, 2026. Release 1.7.0 arrived eight days earlier and added 9 services alongside substantial CloudFormation, IAM, Cognito, S3, and container work. The repository had no non-pull-request issues in the first 20 recently updated open items we fetched, so we cannot cite a current user defect from that sample. Release traffic still shows fast movement across many APIs.

Floci is worth testing for local AWS work, especially where LocalStack Community changes forced a choice. Begin with the 2 or 3 services that dominate the application's tests. Confirm create, update, error, and cleanup behavior, then add more services only after the suite proves useful. That approach captures Floci's free local feedback without confusing emulator compatibility with AWS certification. The project is broad enough to replace a local stack, but only the application's own calls can decide whether it does.

Alternatives

ProjectWhat it isPick it when
LocalStack gh↗The established local AWS cloud emulator with community and commercial offerings.pick this instead when its ecosystem, support contracts, or operation coverage matter more than Floci's token-free MIT model.
MotoA Python library and server for mocking many AWS APIs in tests.pick this instead when Python tests need lightweight API mocks and real container-backed services are unnecessary.
AWS SAM CLIAWS's local tooling for building and invoking serverless applications.pick this instead when the project is centered on Lambda and API Gateway through the SAM workflow.

What people are saying

  1. [velocity-scout] floci-io/floci

Sources

  1. Floci repository and README
  2. Floci services overview
  3. Floci 1.7.0 release notes
  4. Floci migration guide
  5. Floci storage configuration

More dev tools reviews

workmux · v2rayNG · SecLists · hashcat · eslint · fastfetch · the whole board →