LocalStack vs Floci vs moto — When to Use What (2026 Guide)

You need to test AWS code without touching a real account. Three names come up constantly: LocalStack, Floci, and moto. They are not interchangeable — they solve different layers of the same problem.

This guide explains what each tool actually does, where it breaks down, and how to pick one (or combine two) for local development, CI, and Terraform dry-runs.

Disclosure: Floci is an open-source project by a contributor to this site. This comparison aims to be fair and useful regardless of which tool you choose.

The one-minute answer

Tool	What it is	Best for
moto	In-process Python mocks (@mock_aws)	Fast unit tests, pytest, mocking boto3 calls
LocalStack	Docker-based local AWS cloud	Broad service coverage, established teams, Pro features
Floci	Native binary / Docker AWS emulator (floci.io)	LocalStack-compatible loop, CI, no auth token, multi-cloud (AWS/Azure/GCP)

Rule of thumb: moto for speed in Python unit tests; LocalStack or Floci for integration tests and local dev that hit a real HTTP endpoint.

---

What each tool actually is

moto — mock library, not a cloud

moto patches boto3/botocore inside your Python test process. When your code calls s3.create_bucket(), moto intercepts the call and returns a fake response — no network, no container.

import boto3
from moto import mock_aws

@mock_aws
def test_upload():
    s3 = boto3.client("s3", region_name="ap-south-1")
    s3.create_bucket(Bucket="my-test-bucket")
    s3.put_object(Bucket="my-test-bucket", Key="hello.txt", Body=b"hi")
    assert s3.get_object(Bucket="my-test-bucket", Key="hello.txt")["Body"].read() == b"hi"

Strengths

• Starts instantly — no Docker pull, no port binding
• Ideal for CI matrices with hundreds of small tests
• Free, MIT-licensed, huge community
• Works offline on any laptop

Limits

• Python-centric (other languages need different approaches)
• Behaviour is mocked, not emulated — edge cases differ from AWS
• Multi-service flows (S3 event → Lambda → DynamoDB) are harder to validate end-to-end
• Not a target for AWS CLI workflows or Terraform apply

When to use moto: pytest suites, Lambda handler logic, boto3 call patterns, coverage gates in PR checks.

---

LocalStack — the incumbent local AWS cloud

LocalStack runs as a Docker container exposing AWS-compatible APIs on port 4566. Point the AWS CLI, SDKs, or Terraform at http://localhost:4566 and most workflows Just Work™.

export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test
aws s3 mb s3://local-bucket

Strengths

• Widest AWS service surface in this category
• Massive documentation, Stack Overflow answers, team familiarity
• LocalStack Pro adds advanced features (some teams depend on these)
• Same mental model as real AWS — good for onboarding

Limits

• Heavier resource usage than lightweight mocks
• Auth token required for current images/features (a common CI friction point since 2025–2026)
• Startup and idle memory cost matter in ephemeral CI jobs
• Licensing split between Community and Pro — read the fine print before betting the company on Pro-only APIs

When to use LocalStack: teams already standardized on it, you need a specific Pro feature, or your service mix is exotic and only LocalStack implements it today.

---

Floci — native emulator, LocalStack-shaped

Floci is a MIT-licensed local cloud emulator. floci (AWS) uses port 4566 — the same default as LocalStack — so many projects switch by changing the Docker image or binary, not application code.

# Docker — AWS services on :4566
docker run --rm -p 4566:4566 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  floci/floci:latest

export AWS_ENDPOINT_URL=http://localhost:4566
aws s3 mb s3://my-bucket

Floci also ships floci-az (Azure, port 4577) and floci-gcp (GCP, port 4588) — one toolchain for multi-cloud local dev.

Strengths

• No auth token — pull and run; useful for CI, workshops, and AI agent sandboxes
• Fast cold start (~24 ms cited on floci.io) and low idle footprint (~13 MiB)
• Real engines where it matters — e.g. Lambda in Docker, RDS on real PostgreSQL/MySQL, Redis for ElastiCache-shaped APIs
• MIT license with no tier gating on core services
• Drop-in for many LocalStack docker-compose snippets

Limits

• Smaller ecosystem than LocalStack today (fewer blog posts, fewer Stack Overflow answers)
• 66 AWS services — verify your stack before migrating
• Newer project — check GitHub issues for your specific API edge case

When to use Floci: greenfield local dev, CI ephemeral environments, LocalStack token/licensing pain, multi-cloud localhost (AWS + Azure + GCP), or AI-assisted coding loops that need a credential-free endpoint.

---

Side-by-side comparison

Dimension	moto	LocalStack	Floci
Architecture	In-process Python mock	Docker JVM/Python stack	Native binary (GraalVM) / Docker
Default AWS port	N/A (no server)	4566	4566
Auth token	No	Yes (current images)	No
License	MIT	Apache 2.0 + Pro commercial	MIT
AWS CLI / SDK	Via boto3 in tests only	Yes	Yes
Terraform / OpenTofu	Not really	Yes	Yes (endpoint override)
Multi-cloud	AWS only	AWS (+ some extensions)	AWS, Azure, GCP emulators
CI startup cost	Lowest	Higher	Low (claimed)
Fidelity	Mock-level	Emulator-level	Emulator-level (real subprocesses for some services)
Best language	Python	Any (HTTP API)	Any (HTTP API)

---

Decision flowchart

Need to test Python boto3 calls in pytest?
  └─ Yes → moto (maybe + a few integration tests elsewhere)
  └─ No ↓

Need AWS CLI, SDK from Go/Java/Node, or Terraform apply?
  └─ Yes ↓

Already on LocalStack and happy + using Pro features?
  └─ Yes → stay on LocalStack
  └─ No ↓

Auth token / CI cost / startup time blocking you?
  └─ Yes → try Floci (same :4566 endpoint pattern)
  └─ No → LocalStack or Floci — benchmark your stack

Also need Azure Blob or GCP Pub/Sub locally?
  └─ Floci (floci-az :4577, floci-gcp :4588)

---

Common scenarios

Scenario 1: Startup CI on every pull request

Problem: 500 Python unit tests must finish in under 3 minutes.

Pick: moto for 90% of tests. Optionally one nightly job against Floci or LocalStack for a smoke integration suite (S3 + SQS + Lambda).

Scenario 2: Platform team maintains docker-compose for 20 developers

Problem: LocalStack auth token in .env, developers forget to refresh, onboarding breaks.

Pick: Evaluate Floci as a drop-in on port 4566. Keep compose structure; swap image. Run a one-week parallel test with your top 10 AWS API calls.

Scenario 3: Terraform module library

Problem: terraform apply against localhost before prod.

Pick: LocalStack or Floci — both expose HTTP endpoints Terraform providers can target. moto is the wrong tool. Maintain a docker-compose.yml and a TF_VAR_* / provider alias doc in the repo.

Scenario 4: AI coding agent writes cloud infrastructure

Problem: You cannot put real AWS_ACCESS_KEY_ID in the agent context.

Pick: Floci or LocalStack with throwaway test/test keys — Floci emphasises no token and low blast radius for agent loops. Never point agents at production accounts.

Scenario 5: Interview prep / learning AWS without billing

Problem: Freshers practice S3, DynamoDB, Lambda without a credit card.

Pick: Any of the three — Floci or LocalStack for CLI exploration; moto if they’re writing Python exercises. See our DevOps courses guide for structured learning paths.

---

Migration notes

LocalStack → Floci

1. Replace the Docker image in compose: localstack/localstack → floci/floci:latest
2. Keep port 4566 and AWS_ENDPOINT_URL
3. Run your existing integration test suite unchanged
4. File issues for any API mismatch — service parity is never 100% between emulators

Adding moto alongside an emulator

Keep moto for fast PR feedback; run emulator-based tests on main or nightly:

# GitHub Actions sketch
jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - run: pytest tests/unit/        # moto

  integration:
    runs-on: ubuntu-latest
    services:
      floci:
        image: floci/floci:latest
        ports: ["4566:4566"]
    steps:
      - run: pytest tests/integration/  # real HTTP endpoint

---

What none of them replace

Local emulators do not substitute for:

• IAM policy validation in your real org account
• Service quotas, throttling, and regional behaviour
• Cross-account networking (VPC peering, PrivateLink)
• Cost optimisation exercises (use real billing tools for that)

Plan a staging account for pre-production verification. Use localhost tools to shrink the inner loop — not to skip staging entirely.

---

Summary

• moto — fastest, Python-only, unit-test mocks; not a cloud server.
• LocalStack — mature, broad AWS coverage; auth token and resource weight are the trade-offs in 2026.
• Floci — MIT, token-free, port-4566 compatible, multi-cloud; strong for CI, local dev, and credential-free agent sandboxes.

Most effective teams combine moto + one server emulator rather than picking a single winner.

---

Related on FzlOps

• DevOps courses & interview prep — structured learning by stack
• How to crack a DevOps interview in India
• Browse open DevOps & platform roles — updated daily

Practice locally. Apply to roles that match your stack on FzlOps.