LocalStack Alternatives in 2026

The best LocalStack alternative for a TypeScript or Go backend is Encore, which runs the Postgres databases, Pub/Sub topics, buckets and caches your code declares on your laptop with encore run and creates the same resources in your own AWS or GCP account on deploy, with no emulator in between. If you need the AWS APIs themselves, Floci is a free, MIT-licensed drop-in for the LocalStack container on port 4566, and fakecloud is a single-binary emulator built for integration tests. Moto covers Python test suites, the AWS SAM CLI covers Lambda, and Testcontainers runs real Postgres or Redis from your tests.

LocalStack is the usual container for running S3, SQS, DynamoDB and other AWS APIs on a developer machine, and for years the Community image was free to pull in CI, until March 2026, when it became a single image that needs a LocalStack account and an auth token in every pipeline, a change that often surfaced as a failing build.

What they usually want back is a local setup that matches production closely enough to trust, and that question has two different answers depending on whether the code calls AWS APIs directly or only needs a database, a queue and a bucket.

Why are teams looking 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.
• LocalStack's pricing terms limit the free Hobby plan to 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, most noticeably in CI.
• Emulated behavior around IAM, event delivery and timeouts differs from AWS in ways that often only show up after a deploy.

What are the best LocalStack alternatives in 2026?

The ranking puts first the option that removes the most local configuration for a typical backend, and then the tools that emulate or mock AWS for code that needs the APIs directly. Release numbers are from each project's GitHub releases or package registry.

Why is Encore the first LocalStack alternative?

LocalStack usually exists so that the app on a laptop has an S3 bucket, an SQS queue and a database to talk to, and Encore gets there from the other direction with infrastructure from code: the database, the Pub/Sub topic and the bucket are declared in your TypeScript or Go code, encore run starts local versions of each, and a deploy creates RDS, SNS/SQS and S3 (or Cloud SQL, Pub/Sub and Cloud Storage) in your own cloud from the same declarations. There is no emulator to point Terraform at, because there is no separate Terraform for these resources in the first place.

In a receipts flow, for example, LocalStack needs the local bucket and queue to come from an init script or Terraform aimed at port 4566, with the application reading endpoint overrides from environment variables, while with Encore the code below is the whole definition:

import { api, APIError } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic } from "encore.dev/pubsub";
import { Bucket } from "encore.dev/storage/objects";
import { getAuthData } from "~encore/auth";
import { randomUUID } from "node:crypto";

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

// Local topic on `encore run`; SNS/SQS or GCP Pub/Sub in production.
export const orderPlaced = new Topic<{ orderId: string }>("order-placed", {
  deliveryGuarantee: "at-least-once",
});

// Objects on the local filesystem; S3 or Cloud Storage in production.
export const receipts = new Bucket("receipts", { versioned: false });

const maxReceiptBytes = 2 * 1024 * 1024;

export const placeOrder = api(
  { method: "POST", path: "/orders", expose: true, auth: true },
  async ({ pdf }: { pdf: string }): Promise<{ orderId: string }> => {
    const { userID } = getAuthData()!;
    const data = Buffer.from(pdf, "base64");
    if (!pdf || data.length === 0 || data.length > maxReceiptBytes) {
      throw APIError.invalidArgument("PDF is required and must be at most 2 MiB");
    }
    const orderId = randomUUID();
    await db.exec`
      INSERT INTO orders (id, owner_uid) VALUES (${orderId}, ${userID})
    `;
    await receipts.upload(`${userID}/${orderId}.pdf`, data, {
      contentType: "application/pdf",
    });
    await orderPlaced.publish({ orderId });
    return { orderId };
  },
);

placeOrder requires a bearer token, a client idempotency key, and a receipt no larger than 2 MiB. The order id is allocated on the server, the receipt is stored under that user's prefix, and a retry of the same key returns the original order, uploads the receipt only if it is missing, and publishes orderPlaced from an outbox row so a timeout cannot create a second order or a second event. The same declarations drive preview environments for each pull request and production in your account, so the gap between "works on my machine" and "works in AWS" is the gap between the local and managed versions of Postgres, a queue and object storage, not between an emulator and AWS. That matters more once AI coding agents write some of the backend, because an agent that adds a bucket declares it in the same change and can test it with encore run before anyone reviews the pull request.

Key features

• encore run starts every service along with its Postgres databases, Pub/Sub topics, buckets and caches from the declarations in code.
• Secrets are declared in code and set per environment with encore secret set, and the local development dashboard shows a distributed trace for each request, including the queries, publishes and uploads it made.
• Object storage uses the local filesystem in development and an in-memory backend in tests, as described in the object storage docs.
• A deploy provisions the declared resources in your own AWS or GCP account, and you can also build a Docker image with encore build docker and run it on infrastructure you manage.

Good to know

Encore is not an AWS API emulator, so code that calls DynamoDB, Step Functions or Cognito directly through the AWS SDK needs an AWS account or one of the emulators below. Cron jobs do not run on their schedule locally or in preview environments, so you call the cron endpoint directly to test it. Adopting Encore means declaring infrastructure through its APIs, which is a bigger change than swapping a container image, but it can start with one service while the rest of the system keeps its current setup.

See how local development works in Encore.

Is Floci a drop-in replacement for LocalStack?

Floci

Floci is an open source, MIT-licensed AWS emulator that describes itself as a drop-in replacement for the LocalStack container. It runs without an account, auth token or paid feature gates, serves every service on http://localhost:4566 and accepts any non-empty credentials, so the AWS SDKs, CLI, Terraform and CDK keep working against it.

Key features

• It uses the same port (4566) and SDK configuration as LocalStack, so most migrations only change the image name.
• A web console at /_floci/ui shows the emulated resources.
• There are no feature gates or CI quotas, per the project README.

Good to know

Floci is the shortest way to get an existing LocalStack setup working again without a token, and with about 31,000 GitHub stars it has gathered a large user base quickly. Check the operations your code calls against its service list and expect some differences from AWS, as with any emulator. The Terraform or scripts that create local resources still have to be maintained separately from production.

When is fakecloud the better choice?

fakecloud

fakecloud is an AGPL-3.0 AWS emulator that runs as a single binary or a Docker image. 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 or MySQL and Redis or 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.

Is Moto enough for Python tests?

Moto

Moto (5.2.5) mocks AWS services for Python, and the usual pattern is 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. Resources only exist for the duration of a test and behavior such as event delivery between services is limited, which makes it a poor fit for a long-running local environment that a whole team develops against.

When should you use Testcontainers instead of an emulator?

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, since tests run against the actual software. It only covers services that have a container image, so AWS-specific APIs still need an emulator, and its LocalStack module now also needs a token. It is designed for tests, not for a long-running development environment.

Does the AWS SAM CLI replace LocalStack for Lambda?

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 →

Which LocalStack alternative should you pick?

• Encore when your TypeScript or Go backend mostly needs Postgres, Pub/Sub, object storage and caches, and you want one declaration in code to cover local, preview and production.
• Floci when 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.
• Testcontainers for integration tests against real Postgres, Redis or Kafka.
• AWS SAM CLI for Lambda-first apps already defined in SAM templates.

Verdict. An emulator is the right tool when your code calls AWS-specific APIs directly, and Floci is the closest free replacement for the LocalStack container. When the app mainly needs a working database, queue and bucket on a laptop and the same resources in AWS, Encore ranks first, because it removes the emulator and the Terraform behind it instead of replacing them. 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?