Announcing the LocalStack 4.2 Release

Introduction

LocalStack 4.2 brings significant advancements in AWS service emulation, further enhancing the local development experience. With the introduction of AWS Replicator, developers can seamlessly copy AWS resources into LocalStack, reducing the friction between cloud and local environments. The release also expands support across key services, including Shield, Step Functions, and Bedrock, while introducing IAM enforcement for Neptune and improvements in Cloud Pods and DMS. Additionally, various enhancements across API Gateway, EKS, ELB, and Flink reinforce LocalStack’s commitment to providing a robust, feature-rich local cloud environment.

Get your free LocalStack account to access the latest features and enhancements in LocalStack 4.2!

How to upgrade?

To upgrade to LocalStack 4.2 using the LocalStack CLI, run the following command to update both the LocalStack Docker image and CLI to the latest version:

localstack update all

If using LocalStack with Docker CLI or Docker Compose, update the Docker image by running:

docker pull localstack/localstack:4.2.0 # Community Edition
docker pull localstack/localstack-pro:4.2.0 # Pro Edition

Pin the LocalStack version in your docker run command or Docker Compose file to 4.2.0.

What’s new in LocalStack 4.2?

• Introducing LocalStack AWS Replicator
• New Shield Provider
• New enhancements in the Step Functions provider
• New enhancements in the Bedrock provider
• IAM Enforcement for Gremlin Queries in Neptune
• Auto-Loading Cloud Pods from S3 Remote
• Miscellaneous

Introducing LocalStack AWS Replicator

LocalStack AWS Replicator bridges the gap between your AWS cloud environment and your local development by copying AWS resources directly into a running LocalStack instance. This powerful feature removes the need to recreate existing resources or modify your infrastructure stacks to work locally.

AWS Replicator is especially valuable when your applications depend on existing resources like SSM parameters, VPCs, or other infrastructure components. Instead of manually recreating these dependencies, you can replicate them, ensuring they’re available before deploying your main stack.

The replication process is straightforward:

• Authenticate with your AWS credentials to access the source resources
• Specify the resource you want to replicate using its ARN or resource type and identifier
• Trigger the replication job through the LocalStack CLI or HTTP API
• Check the job status to confirm successful replication

AWS Replicator gives you granular control over where resources are replicated, allowing you to specify target AWS account IDs and regions if needed. Currently available as part of the LocalStack Teams plan and higher, AWS Replicator supports a growing list of AWS resource types. This feature integrates with persistence and Cloud Pods, allowing the process (which requires online AWS access) to be a one-time operation.

The feature is in preview state, with expanding support for additional resources coming soon. Check out our AWS Replicator documentation to learn more!

New Shield Provider

LocalStack now supports AWS Shield, a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. This integration allows you to mock and test Shield APIs in your local development environment without connecting to the actual AWS service.

With LocalStack’s Shield implementation, you can create, read, update, and delete Shield protections and subscriptions. While the actual protection mechanisms aren’t applied to resources, this mock implementation enables developers to test Shield-related configurations and workflows.

Learn more about LocalStack’s Shield provider in our documentation.

New enhancements in the Step Functions provider

LocalStack’s Step Functions provider now includes the following enhancements:

• Step Functions provider now features optimized service integration for Glue.
• Step Functions interpreter now validates unsupported API actions in optimized service integrations at creation time instead of only at runtime. It also adds logging for missing request/return types and reports errors for unsupported service tasks.

New enhancements in the Bedrock provider

LocalStack’s Bedrock provider now includes the following enhancements:

• Bedrock provider now supports on-demand model switching by specifying a model ID prefixed with ollama. for each request. For example, to access deepseek-r1, use the following:
  

  awslocal bedrock-runtime converse \
      --model-id "ollama.deepseek-r1" \
      --messages '[{
          "role": "user",
          "content": [{
              "text": "Say Hello!"
      }]
  }]'

• Bedrock provider now supports pulling multiple models on LocalStack startup with a new BEDROCK_PULL_MODELS configuration option. This option allows you to specify a comma-separated list of model IDs to pull from the Ollama models library on startup.

• Ollama logs from the Bedrock provider are now streamed directly to LocalStack logs.

IAM Enforcement for Gremlin Queries in Neptune

Neptune now enforces IAM permissions for Gremlin queries. When creating a cluster with IAMDatabaseAuthenticationEnabled=true, Gremlin queries must be signed for READ, WRITE, or DELETE operations. This applies only to users setting LOCALSTACK_ENFORCE_IAM and LOCALSTACK_IAM_SOFT_MODE configuration variables when starting LocalStack.

Read more about IAM Security Testing in our documentation.

Auto-Loading Cloud Pods from S3 Remote

LocalStack now supports automatically loading a Cloud Pod from a registered S3 remote. To configure this, add the remote name to a text file inside init-pods.d:

foo-pod,bar-remote

With this setup, the foo-pod Cloud Pod will be loaded from the bar-remote remote.

To configure the remote properly, provide the required environment variables when starting the LocalStack container. For example, an S3 remote requires:

AWS_ACCESS_KEY_ID=your_access_key_id \
AWS_SECRET_ACCESS_KEY=your_secret_access_key \
DOCKER_FLAGS='-v /path/to/init-pods.d:/etc/localstack/init-pods.d' \
localstack start

However, auto-load feature does not automatically configure the remote. Configure it with localstack pod remote add command which creates a configuration file for the remote in the LocalStack volume directory. Learn more about this feature in our documentation.

Miscellaneous

• LocalStack now supports Binary media for API Gateway REST APIs, allowing payloads to be passed as-is, converted to UTF-8, or base64 encoded/decoded.
• EKS now supports Kubernetes versions 1.31 and 1.32. The default version is set to 1.31, in parity with the latest supported version in AWS.
• ELB listeners now support any port matching the GATEWAY_LISTEN configuration variable instead of only the first port.
• You can now use the MWAA_DOCKER_FLAGS configuration variable while starting the LocalStack container to pass extra flags when starting an Airflow container with MWAA.
• Managed Service for Apache Flink now supports forwarding application logs created with Log4j or SLF4J to CloudWatch Logs.
• LocalStack now supports PostgreSQL as a source in the Database Migration Service (DMS) provider.

Conclusion

LocalStack 4.2 fundamentally addresses the configuration drift challenge that has plagued local cloud development with our new AWS Replicator feature. Additionally, we are expanding our capabilities with new service providers and enhancements across the board. These improvements aren’t incremental features but architectural enhancements that significantly reduce the gap between local development and production environments, allowing developers to build more resilient cloud applications with greater confidence in deployment outcomes. We aim to make LocalStack an essential component in robust cloud application testing rather than just a convenient development shortcut, and we aim to work closely with our community to achieve this goal. Upgrade to LocalStack 4.2 today and experience our latest advancements firsthand!