LocalStack Alternatives in 2026

LocalStack is the container most teams use to run S3, SQS, DynamoDB and other AWS APIs on their own machine, and for years the Community image was free to pull in CI. Since March 2026 it ships as a single image that needs a LocalStack account and an auth token in every pipeline, so many teams found out about the change from a failing build and started looking at what else they could run locally. This article covers the options teams usually compare, which are Encore, Floci, fakecloud, Moto, the AWS SAM CLI and Testcontainers.

Reasons teams look for LocalStack alternatives:

• CI started failing once localstack/localstack:latest began requiring LOCALSTACK_AUTH_TOKEN, and now every pipeline and every developer needs a token.
• The free Hobby plan is for non-commercial use, so a commercial team either pays for a plan or pins an old tag that no longer gets updates.
• The local setup is usually Terraform or CDK pointed at the emulator, which is a second set of configuration that has to be kept in sync with production.
• Startup time and image size slow down the feedback loop, and this is most noticeable in CI.
• Emulated behavior around IAM, event delivery and timeouts differs from AWS in ways that often only show up after a deploy.

LocalStack alternatives at a glance

Encore: local infrastructure from your application code

Encore combines the local and production sides of the setup that many teams use LocalStack for, where the app needs a database, a queue and a bucket on a laptop while production uses RDS, SQS and S3. You declare the Postgres database, the Pub/Sub topic and the bucket in your TypeScript or Go code, encore run starts them locally (Postgres runs in Docker) without an emulator to configure, and a deploy creates the same resources in your own AWS or GCP account, so there is no separate Terraform setup to point at an emulator.

import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic } from "encore.dev/pubsub";
import { Bucket } from "encore.dev/storage/objects";

// Local Postgres with migrations applied on `encore run`; RDS or Cloud SQL in production.
export const db = new SQLDatabase("orders", { migrations: "./migrations" });

// In-memory Pub/Sub locally; SNS/SQS or GCP Pub/Sub in production.
export const orderPlaced = new Topic<{ orderId: string }>("order-placed", {
  deliveryGuarantee: "at-least-once",
});

// Local disk storage; S3 or Cloud Storage in production.
export const receipts = new Bucket("receipts", { versioned: false });

Key features

• encore run starts every service along with its Postgres databases, Pub/Sub topics, buckets and caches, and since local Postgres runs in Docker you need Docker installed but no Docker Compose file.
• Secrets and cron jobs are declared in code in the same way as the other resources, and the local development dashboard shows a distributed trace for each request.
• A deploy provisions the declared resources in your own AWS or GCP account, and the app has no runtime dependency on Encore.
• SDKs are available for TypeScript, Go, Python and Rust.

Good to know

Encore is not an AWS API emulator, so code that calls DynamoDB, Step Functions or Cognito directly through the AWS SDK still needs a real account or one of the emulators below. Cron jobs do not run on their schedule in local development, so developers call the cron endpoint directly to test it. Moving to Encore means declaring infrastructure through its SDK, which is a bigger change than swapping a container image, but adoption can be incremental, starting with one service while the rest of the setup stays as it is.

See how local development works in Encore.

Floci: a free drop-in AWS emulator

Floci

Floci is an open-source, MIT-licensed AWS emulator that is built as a replacement for the LocalStack container, and it runs without an account or auth token and sends no telemetry.

Key features

• It uses the same port (4566), dummy credentials and SDK configuration as LocalStack, so most migrations only change the image.
• A -compat image variant includes the AWS CLI, Python and boto3 for init scripts.
• There are no feature gates or CI quotas.

Good to know

Floci is the shortest way to get an existing LocalStack setup working again without a token. It is a young project, so check its services overview for the operations your code calls and expect some differences from AWS, as with LocalStack, and the Terraform or scripts that create local resources still have to be maintained separately from production.

fakecloud: an AWS emulator built for integration tests

fakecloud

fakecloud is an AGPL-3.0 AWS emulator that runs as a single binary or a Docker image, and next to the AWS APIs it ships test SDKs for TypeScript, Python, Go, PHP, Java, Rust and .NET that let a test reset state and inspect side effects such as SES emails, SNS messages or Lambda invocations.

Key features

• It runs as a standalone binary without Docker, or as a Docker image.
• The service list includes RDS and ElastiCache, which are backed by real Postgres/MySQL and Redis/Valkey containers.
• The assertion SDKs can inspect side effects and trigger async processing on demand during a test.

Good to know

fakecloud fits teams whose integration tests need to assert on AWS side effects and not only call the APIs. Its coverage and conformance numbers are self-reported, so verify the services you depend on, and check the AGPL-3.0 license against your company's policy even though it is usually acceptable for a development and test tool.

Moto: AWS mocks for Python tests

Moto

Moto mocks AWS services for Python, and most teams use its @mock_aws decorator inside pytest, although it also has a standalone server mode that any AWS SDK can call.

import boto3
from moto import mock_aws

@mock_aws
def test_upload_receipt():
    s3 = boto3.client("s3", region_name="us-east-1")
    s3.create_bucket(Bucket="receipts")
    s3.put_object(Bucket="receipts", Key="r1.pdf", Body=b"...")
    assert s3.list_objects_v2(Bucket="receipts")["KeyCount"] == 1

Key features

• Mocks run in-process for Python, with no container to start.
• Other languages can use moto_server or the motoserver/moto Docker image.
• A reset API and a dashboard at /moto-api/ show the current state.

Good to know

Moto works well for unit and integration tests in Python codebases. Because it mocks AWS inside the test process, resources only exist for the duration of a test and behavior such as event delivery between services is limited, so it is less suited to a long-running local environment that a whole team develops against.

AWS SAM CLI: Lambda functions on your machine

AWS SAM CLI

The AWS SAM CLI runs Lambda functions and API Gateway endpoints locally in Docker containers that match the Lambda runtime, using your SAM template.

Key features

• sam local invoke and sam local start-api run functions in Lambda-like containers.
• It can generate sample events for SQS, S3 and other triggers.
• sam deploy deploys the same template.

Good to know

SAM covers the compute side of a serverless app and does not emulate the databases, queues or buckets the function talks to, so teams usually combine it with real AWS resources in a dev account or with an emulator. It only works with AWS and depends on SAM or CloudFormation templates.

Try AWS SAM →

Testcontainers: real services in your tests

Testcontainers is a set of libraries for Java, Go, Node.js, Python, Rust, .NET and other languages that start throwaway Docker containers from test code, so instead of emulating RDS or ElastiCache you test against a real Postgres or Redis.

from testcontainers.postgres import PostgresContainer

def test_orders_repository():
    with PostgresContainer("postgres:17") as pg:
        url = pg.get_connection_url()
        # run migrations and queries against a real Postgres

Key features

• Modules exist for Postgres, MySQL, Redis, Kafka, RabbitMQ, MinIO and many other services.
• The test run creates the containers and cleans them up afterwards.
• It behaves the same on laptops and in CI as long as a Docker daemon is available.

Good to know

Testcontainers is the closest to production for open-source services because tests run against the actual software, but it only covers services that have a container image, so AWS-specific APIs still need an emulator (its LocalStack module now also needs a token). It is designed for tests rather than for a long-running development environment.

How to choose

• Encore if your app mostly needs Postgres, Pub/Sub and object storage, and the team would rather declare them once in code than keep emulator config and Terraform in sync.
• Floci if you want your existing LocalStack setup working again without an account and with as few changes as possible.
• fakecloud for integration tests that need to assert on AWS side effects.
• Moto for Python test suites using boto3.
• AWS SAM CLI for Lambda-first apps already defined in SAM templates.
• Testcontainers for integration tests against real Postgres, Redis, or Kafka.

An emulator is useful when your code calls AWS-specific APIs directly, but when the app mainly needs a working database, queue and bucket on a laptop and the same resources in AWS, you can declare them in code with Encore and skip the emulation layer. The quickstart shows what encore run starts locally.

Related guides

• Local development with Encore
• Do you need Terraform?
• Replace Docker Compose and Terraform
• What is a sandbox environment?