Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Use LocalStack to run integration tests against emulated AWS APIs on a developer machine or in CI: start the emulator, point AWS tools or SDKs at its endpoint, provision test resources, run the application tests, and save logs and reports. This verifies the interactions covered by the emulated services; it does not prove that every service, account setting, or production condition will behave identically in real AWS.

What LocalStack tests—and what it does not

LocalStack is a containerized AWS service emulator for local development and CI. Its getting-started documentation names Lambda, DynamoDB, S3, and SQS among supported services and describes coverage of more than 80 services. Check the current supported APIs for the exact services and operations your application uses; a service being listed is not a guarantee of complete behavioral parity with AWS. LocalStack Getting Started Overview

Use LocalStack to exercise application code that calls AWS APIs without requiring each test run to depend on a live AWS environment. Where correctness depends on real AWS behavior—such as account configuration, permissions, or production-specific conditions—add an appropriate validation against AWS as a separate testing boundary.

Choose a local startup and endpoint approach

Start with the LocalStack CLI

Docker is required. LocalStack recommends its lstk CLI for local startup; the documented quickstart also requires a LocalStack account and Auth Token. After installing the CLI and authenticating, run lstk start. The quickstart reports the endpoint as localhost.localstack.cloud:4566. See Installation and Local Development.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For a team that wants a reusable, checked-in container definition, Docker Compose is another option. It makes container configuration explicit in the project, while lstk provides an integrated install, authentication, and startup workflow. Choose based on how your team manages local infrastructure rather than assuming one route fits every project.

Point AWS clients at the emulator

Use an explicit endpoint such as http://localhost.localstack.cloud:4566 or http://localhost:4566, or use transparent endpoint injection. Explicit configuration makes the test target visible in application or test setup. Injection can avoid changing application code, according to LocalStack’s SDK guidance; the right trade-off depends on your test harness and project conventions. See AWS SDKs.

The lstk aws and lstk terraform wrappers can route those commands to LocalStack. SDK endpoint configuration is useful when tests create resources through the application or a test fixture instead.

Build a repeatable local test loop

  1. Start Docker. Confirm the Docker daemon is running before starting LocalStack.
  2. Install and authenticate the CLI. Follow LocalStack’s current installation and account instructions, then supply the required Auth Token.
  3. Start the emulator. Run lstk start and use the endpoint it reports.
  4. Provision only what the test needs. Create resources through IaC, lstk aws/lstk terraform, or test setup code that targets the local endpoint.
  5. Run integration tests. Configure the AWS client or endpoint injection before the application makes service calls.
  6. Reset state deliberately. Prefer a fresh environment or explicit cleanup between runs so tests do not depend on resources left by earlier runs.

For tests that run inside containers, LocalStack documents language integrations using Testcontainers; see Testcontainers. Container networking and Docker access must match the way the test and emulator are launched.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Run LocalStack in CI

  1. Store the Auth Token as a protected secret. Add it to the CI provider’s secret manager and expose it to the job as LOCALSTACK_AUTH_TOKEN. Do not commit it to workflow files.
  2. Provide container access. Install or use a runner with Docker available, and verify that the job has access to the daemon/socket required by the services under test.
  3. Install the test tooling. Install lstk and any AWS, IaC, or language test tools not already available on the runner.
  4. Start LocalStack. Run lstk start; LocalStack’s GitHub Actions guide says this command waits until the service is ready.
  5. Create test infrastructure and run tests. Apply IaC, run test setup, or load a snapshot, then point the application tests at the LocalStack endpoint.
  6. Export evidence before teardown. Save LocalStack logs and test reports as CI artifacts, including when tests fail. The runner is usually ephemeral, so artifacts must be collected before it shuts down.

For general CI design recommendations, see LocalStack’s CI Pipelines Overview and CI Best Practices.

GitHub Actions and runner caveats

For GitHub Actions, follow LocalStack’s current direct-lstk workflow and provide LOCALSTACK_AUTH_TOKEN from GitHub Secrets rather than placing the token in the workflow source. LocalStack’s guide says Windows runners cannot run LocalStack natively. It also notes that arm64 Lambda emulation may require QEMU and can make builds slower. Confirm the current runner guidance before choosing an architecture or service combination. LocalStack GitHub Actions

Choose a test-state strategy

Fresh state for independent runs

For most local and CI test runs, start clean and create the resources the test requires. This makes hidden dependencies on prior runs less likely and helps make failures reproducible.

Snapshots or persistence for deliberate continuity

Use snapshots or persistence when a workflow intentionally needs state to cross a job boundary. Treat that as an explicit dependency: document how the state is produced, when it is refreshed, and which tests consume it. LocalStack’s CI guidance covers persistence and state management in more detail: CI Best Practices.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Infrastructure, repeatability, and cost considerations

  • Docker permissions: Some services, including Lambda and ECS use cases, may start additional containers. The runner therefore needs suitable Docker daemon/socket access, and its networking must permit the test and emulator to communicate.
  • Pin versions: Pin the LocalStack image version where repeatability matters, rather than allowing an unplanned image change to alter a test environment.
  • Keep jobs isolated: A clean, ephemeral environment usually makes independent CI runs easier to reason about. Retain only the logs and reports needed for diagnosis; use persistence or snapshots only when the pipeline requires state continuity.
  • Check plan and feature access: LocalStack’s licensing documentation, as of March 23, 2026, says Base, Ultimate, and Enterprise are commercial subscriptions and Hobby is for non-commercial use. Verify the current plan matrix, Auth Token status, and access to the exact services and features before adopting a workflow. LocalStack Plans
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Troubleshoot common failures

  • lstk start cannot reach Docker: Start the Docker daemon and check runner socket permissions. This is especially important when a tested service launches nested containers.
  • AWS calls reach real AWS or fail to connect: Confirm the SDK endpoint is explicitly set to the LocalStack endpoint, or verify endpoint injection is active. Check whether the caller runs on the host or inside another container, since the correct network address can differ.
  • Resources appear to be missing between tests: Check whether the environment was reset or the job is fresh. Provision resources for each independent run, or deliberately configure and document persistence/snapshot loading.
  • CI fails despite working locally: Compare Docker access, networking, operating system, and CPU architecture. For GitHub Actions, account for the documented Windows runner limitation and possible QEMU overhead for arm64 Lambda workloads.
  • A service operation behaves differently than expected: Confirm that the specific API operation is covered by the current LocalStack service implementation. Treat the emulator as validation of tested interactions, not proof of complete AWS equivalence.
  • Job failure leaves no useful diagnostics: Export LocalStack logs and test reports in an always-run artifact step so they survive test failure and runner teardown.
  • Authentication or service access fails: Check that the token is available to the job as LOCALSTACK_AUTH_TOKEN and that the current plan and token provide the feature access your workload needs.

Or skip the browser setup

If a test workflow also needs clean website screenshots, ScreenshotNeo provides a one-call screenshot API; it is separate from LocalStack and does not emulate AWS services.

cURL example (see the ScreenshotNeo documentation):

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Learn about ScreenshotNeo or sign up for free.

Frequently Asked Questions

Can LocalStack prove that an application will behave identically in AWS?

No. It tests interactions with emulated services; validate production-specific behavior against AWS where that behavior matters.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Do tests running in containers need a special integration?

Not necessarily, but LocalStack documents Testcontainers integrations for containerized test workflows; networking and Docker access still need to be configured for the environment.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.