Learn LocalStack - Latest Stable Features (2026.x)

#Introduction

In the previous episode 19 we handled performance and troubleshooting: reading localstack logs, checking the /_localstack/health health endpoint, and solving classic problems like the 4566 port conflict or Lambda not being invoked. But there's one thing you often overlook: the LocalStack version you're running.

AWS releases features almost every week, and LocalStack chases that parity. Since 2026, their release numbering changed completely, the image became one, and features that used to be Pro-only can now be tried by everyone. This episode maps calendar versioning, release tags, and the latest stable features in 2026.07.0 — so you know what's ready to mimic production, and what's still too young to rely on.

#Calendar Replaces SemVer

#The YYYY.MM.patch Format

LocalStack used to use SemVer like 3.x or 4.x. SemVer is good for flagging breaking changes, but doesn't answer the most practical question: "which month was this release born in?" Since 2026.03.0, LocalStack uses calendar versioning with the YYYY.MM.patch format:

• YYYY = release year, MM = main release month, patch = fixes within the same month.
• Real examples: 2026.03.0, then 2026.07.0; the CLI on PyPI follows the localstack 2026.7.x pattern.

The benefit is immediately felt by teams: if the image you're pinned to comes from early 2026 while the latest release is already 2026.07.0, it's obvious that months of feature parity are still missing. Checking the running version only takes two commands:

localstack --version
localstack status

#One Image for Community and Pro

There used to be two images: localstack/localstack for Community and localstack/localstack-pro for Pro. Since 2026.03.0 both merge into a single localstack/localstack image. Feature tiers are now determined by configuration, not the image: provide LOCALSTACK_API_KEY and Pro features activate; without the key, the same image runs as Community.

The pleasant consequence: no more risk of pulling the "wrong" image. Just set the environment variable then localstack restart to reload.

#Four Release Tags

LocalStack offers four image tags to control how much exposure you have to change:

• stable — tested release; safest for CI and daily work.
• latest — alias for the latest official release; practically identical to stable.
• dev — development build; carries new features but can change without warning.
• nightly — nightly build; for peeking at in-progress features, not for production.

#The 2026 Release Map

The following table summarizes the release trajectory through 2026 and how it relates to the learning phases we've gone through:

#Stable Features in 2026.07.0

#Step Functions HTTP Tasks with EventBridge Connections

Step Functions now supports HTTP Tasks that call external APIs via arn:aws:states:::http:invoke. The authorization lives in EventBridge Connections (API key, basic auth, or OAuth) and is then referenced from the state machine. This opens up real scenarios that were impossible to test locally before: workflows that call third-party webhooks.

{
  "StartAt": "CallWebhook",
  "States": {
    "CallWebhook": {
      "Type": "Task",
      "Resource": "arn:aws:states:::http:invoke",
      "Parameters": {
        "ApiEndpoint": "https://api.example.com/ping",
        "Method": "GET",
        "ConnectionARN": "arn:aws:events:us-east-1:000000000000:connection/MyConn"
      },
      "End": true
    }
  }
}

#Aurora DSQL: CRUD and SQL Dialect

Aurora DSQL now supports full CRUD operations along with a more complete SQL dialect — CREATE TABLE, INSERT, SELECT, UPDATE, DELETE, joins, and simple transactions. Connections happen through the DSQL endpoint with the PostgreSQL protocol, so standard drivers and tooling work right away. Start by creating a cluster:

awslocal dsql create-cluster --region us-east-1
awslocal dsql list-clusters --region us-east-1

Running statements follows the real AWS pattern: aws dsql-data execute-statement --endpoint-url http://localhost:4566.

#S3 Replication (Since 2026.06)

Since the 2026.06 release, S3 replication is fully supported: from source bucket to destination bucket, with prefix and tag filtering, delete marker replication, and ownership override. Enabling it is identical to real AWS — create the destination bucket, then attach the configuration:

awslocal s3api put-bucket-replication \
  --bucket source-bucket --replication-configuration file://replication.json

After that, upload an object and verify it lands in the destination with awslocal s3 ls s3://destination-bucket.

#Lambda .NET 10 Runtime

LocalStack adds .NET 10 as a Lambda runtime, following the official AWS runtime list. The flow is the same as episode 7: build the project, package it as a zip, then deploy with --runtime dotnet10:

awslocal lambda create-function --function-name dotnet-fn \
  --runtime dotnet10 --role arn:aws:iam::000000000000:role/lambda-role \
  --handler Function::Function.Function::Handler --zip-file fileb://function.zip

Remember: a new runtime means version support, not an emulation architecture change — execution still depends on the chosen LAMBDA_EXECUTOR.

#EKS: Pod Identity and Karpenter Node Join

Two important improvements to EKS emulation. First, EKS Pod Identity — pods obtain an IAM role based on identity, not just a service account token. Second, more realistic node joins, including simulated node auto-scaling by Karpenter. The impact on pipelines is big: from kubectl apply to the pod getting credentials, the entire workload identity and capacity provisioning flow can now be tested end-to-end on a laptop.

#Other Parity Improvements

Besides the features above, 2026.07.0 brings parity refinements that bring emulation even closer to real AWS:

• SQS concurrent pollers — multiple consumers can receive messages from the same queue in parallel, mirroring at-least-once semantics.
• CloudFormation DynamoDB in-place update — changing table attributes like a GSI through a stack without a full replacement.
• S3 Tables — managed table buckets are becoming stable, suitable for analytics workloads.

#Keeping Versions Consistent

A consistent version is a prerequisite for a reproducible environment. The easiest way: pin the stable tag in docker-compose.yml and make sure all developers and CI use the same version.

services:
  localstack:
    image: localstack/localstack:stable
    ports:
      - "4566:4566"
    environment:
      - SERVICES=s3,dynamodb,lambda
      - PERSISTENCE=1

Record the version proven to work in commit messages or the project changelog — this saves you from debugging "works on my machine" that's actually "works on my version".

#Closing

Summary of this episode:

• LocalStack uses calendar versioning YYYY.MM.patch since 2026.03.0; the latest stable release is 2026.07.0.
• The localstack/localstack image is now a single one for Community and Pro; Pro features activate via LOCALSTACK_API_KEY.
• The stable/latest/dev/nightly tags give you control over exposure to change.
• 2026.07.0 brings Step Functions HTTP Tasks with EventBridge Connections, Aurora DSQL with CRUD and SQL dialect, S3 replication, Lambda .NET 10, EKS pod identity and Karpenter, plus SQS and CloudFormation parity.
• Pin the same version locally and in CI for a reproducible environment.

Knowing the contents of the latest release is only half the journey. In episode 21 we place LocalStack within the SDLC: from development and unit testing to integration testing, migration strategies to real AWS in staging and CI, plus Pro features like Cloud Pods, Web Application, and AWS Replicator. See you there!