From 4b43517b250aefd59e6733875c7402ce06ae68ba Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Fri, 14 Aug 2026 11:57:45 +1200
Subject: [PATCH 01/18] Convert terraform-with-testcontainers tutorial.

---
 ...orm-with-testcontainers-and-localstack.mdx | 69 +++++++++++++++----
 1 file changed, 55 insertions(+), 14 deletions(-)

diff --git a/src/content/docs/aws/tutorials/using-terraform-with-testcontainers-and-localstack.mdx b/src/content/docs/aws/tutorials/using-terraform-with-testcontainers-and-localstack.mdx
index 8cffa603..fd0ad9bf 100644
--- a/src/content/docs/aws/tutorials/using-terraform-with-testcontainers-and-localstack.mdx
+++ b/src/content/docs/aws/tutorials/using-terraform-with-testcontainers-and-localstack.mdx
@@ -40,11 +40,11 @@ For this tutorial, you will need:
 - [LocalStack for AWS](/aws/getting-started/auth-token) to emulate the AWS services and to use LocalStack Extensions.
   If you don't have LocalStack for AWS yet, you can sign up on our [webapp](https://app.localstack.cloud) to get a trial license for free.
 - [Docker](https://docker.io/)
-- [LocalStack CLI](/aws/getting-started/installation)
+- [`lstk`](/aws/getting-started/installation#lstk)
 - [AWS CLI](https://aws.amazon.com/cli/)
 - Optional for building the Lambda functions: [Java 17](https://openjdk.org/install/)
 - Optional for building the Lambda functions: [Apache Maven 3.9.8](https://maven.apache.org/install.html)
-- Optional: [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) and [tflocal](https://github.com/localstack/terraform-local)
+- Optional: [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) and [`lstk terraform`](/aws/connecting/infrastructure-as-code/terraform#lstk-terraform)
 
 ## Project overview
 
@@ -71,24 +71,66 @@ on their official documentation page.
 
 #### LocalStack CLI
 
-In the root folder of the demo project run:
+`lstk` takes container environment variables and bind mounts from its [`config.toml`](/aws/developer-tools/running-localstack/lstk/#configuration)
+rather than from command-line flags.
+In the root folder of the demo project, create a project-local `.lstk/config.toml`:
+
+```toml title=".lstk/config.toml"
+[[containers]]
+type = "aws"
+tag  = "latest"
+port = "4566"
+env  = ["terraform-init"]
+volumes = [
+    "../terraform:/etc/localstack/init/ready.d",
+]
+
+[env.terraform-init]
+EXTENSION_AUTO_INSTALL = "localstack-extension-terraform-init"
+```
+
+:::note
+Relative host paths in `volumes` are resolved against the directory that holds `config.toml` — here `.lstk/` — which is why the mount is written as `../terraform` rather than `./terraform`.
+:::
+
+`main.tf` refers to the Lambda JAR as `target/product-lambda.jar`, relative to the Terraform working directory.
+Build it and stage it inside `terraform/`, so that the single mount above carries both the configuration and the JAR into the container:
 
 ```bash
-export LOCALSTACK_AUTH_TOKEN=<your_auth_token>
-localstack start -e EXTENSION_AUTO_INSTALL=localstack-extension-terraform-init \
-    -v ./terraform/main.tf:/etc/localstack/init/
+mvn clean package -DskipTests
+mkdir -p terraform/target
+cp target/product-lambda.jar terraform/target/product-lambda.jar
+```
+
+Then start LocalStack from the project root:
+
+```bash
+lstk start
 ```
 
 This is the easiest way to quickly spin up the desired services at startup.
-The command starts LocalStack with the configuration to automatically install the **`localstack-extension-terraform-init`** [extension](/aws/customization/integrations/extensions/) and
-mount the necessary files into the container: the Terraform configuration file and the Lambda JAR file.
+The [`env` profile](/aws/developer-tools/running-localstack/lstk/#passing-environment-variables-to-the-container) tells LocalStack to automatically install the **`localstack-extension-terraform-init`** [extension](/aws/customization/integrations/extensions/), and
+the [`volumes` entry](/aws/developer-tools/running-localstack/lstk/#volume-mounts) mounts the Terraform configuration and the Lambda JAR into the container.
 The extension will install both `terraform` and `tflocal` into your LocalStack container, and enable the init hook runners to detect Terraform files.
 You can also organize your Terraform files into subdirectories if you want.
 
-If Docker gives you any trouble regarding mounting permissions, you can add `$(pwd)` in front of the local paths, to turn them into
-absolute paths.
+Since the initialization hook runs `terraform init`, the AWS Terraform provider would be downloaded in the container on every start. Mounting the whole `terraform` directory, as above, avoids this: any Terraform state including the `.terraform` folder that contains the provider will be cached on your host directory, however it may require `sudo` permissions to modify or delete, as it is created by the container.
+
+Once the `Ready.` message appears, you can list what the init hook created:
+
+```bash
+lstk status
+```
 
-Since the initialization hook runs `terraform init`, the AWS Terraform provider will be downloaded in the container every time. You can avoid this by mounting a directory instead of a single file. Any Terraform state including the `.terraform` folder that contains the provider, will be cached on your host directory, however they may require `sudo` permissions to modify or delete, as they are created by the container.
+```bash title="Output"
+~ 5 resources · 4 services
+  SERVICE     RESOURCE     REGION     ACCOUNT
+  ApiGateway  nq7sycvcbw   us-east-1  000000000000
+  DynamoDB    Products     us-east-1  000000000000
+  IAM         productRole  global     000000000000
+  Lambda      add-product  us-east-1  000000000000
+  Lambda      get-product  us-east-1  000000000000
+```
 
 #### Docker compose
 
@@ -135,9 +177,8 @@ After running `docker compose up`, we should keep an eye on the container logs u
 Now we can test the functionality of our stack by running the following commands:
 
 ```bash
-aws apigateway get-rest-apis \
-    --query 'items[?name==`product-api-gateway`].id' \
-    --endpoint http://localhost.localstack.cloud:4566
+lstk aws apigateway get-rest-apis \
+    --query 'items[?name==`product-api-gateway`].id'
 ```
 
 ```bash title="Output"

From dba496964a3630e3081c4e41b8c2c0e0aa859314 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Mon, 17 Aug 2026 09:31:47 +1200
Subject: [PATCH 02/18] Convert serverless-quiz-app

---
 .../aws/tutorials/serverless-quiz-app.mdx     | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/src/content/docs/aws/tutorials/serverless-quiz-app.mdx b/src/content/docs/aws/tutorials/serverless-quiz-app.mdx
index 0b6f91f3..60b26c7c 100644
--- a/src/content/docs/aws/tutorials/serverless-quiz-app.mdx
+++ b/src/content/docs/aws/tutorials/serverless-quiz-app.mdx
@@ -30,8 +30,8 @@ Using LocalStack, we can develop and test this entire serverless infrastructure
 For this tutorial, you will need:
 
 - [LocalStack for AWS](https://localstack.cloud/pricing/) with a valid auth token
-- [AWS CLI](https://docs.localstack.cloud/user-guide/integrations/aws-cli/) with [`awslocal` wrapper](https://docs.localstack.cloud/user-guide/integrations/aws-cli/#localstack-aws-cli-awslocal)
-- [AWS CDK](https://docs.localstack.cloud/user-guide/integrations/aws-cdk/) with [`cdklocal` wrapper](https://github.com/localstack/aws-cdk-local) (**optional**)
+- [AWS CLI](https://docs.localstack.cloud/user-guide/integrations/aws-cli/) with [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws)
+- [AWS CDK](https://docs.localstack.cloud/user-guide/integrations/aws-cdk/) with [`lstk cdk`](/aws/connecting/infrastructure-as-code/aws-cdk#aws-cdk-cli-for-localstack) (**optional**)
 - [Python 3.11+](https://www.python.org/downloads/) and `pip`
 - [curl](https://curl.se/) for testing API endpoints
 - [`make`](https://www.gnu.org/software/make/) (**optional**, but recommended for running the sample application)
@@ -90,8 +90,7 @@ pip install -r tests/requirements-dev.txt
 First, start LocalStack with your auth token:
 
 ```bash
-localstack auth set-token <your-auth-token>
-localstack start
+lstk start
 ```
 
 ### Deploy the Infrastructure
@@ -110,10 +109,11 @@ bin/deploy.sh
 
 Alternatively, deploy using AWS CDK with LocalStack:
 
+{/* lstk migration: this script (in the external sample repo) takes the wrapper binary as a single-word env var (AWS_CMD/CDK_CMD) — `lstk aws`/`lstk cdk` are two-word invocations that may not work as a drop-in value depending on how deploy_cdk.sh invokes them. Review the script before relying on this */}
 ```bash
 cd cdk
-cdklocal bootstrap
-AWS_CMD=awslocal CDK_CMD=cdklocal bash ../bin/deploy_cdk.sh
+lstk cdk bootstrap
+AWS_CMD="lstk aws" CDK_CMD="lstk cdk" bash bin/deploy_cdk.sh
 ```
 
 Both deployment methods will:
@@ -150,6 +150,9 @@ Navigate to the CloudFront URL from the deployment output to interact with the q
 Run the complete test suite to validate quiz creation, submission, and scoring:
 
 ```bash
+export AWS_DEFAULT_REGION=us-east-1
+export AWS_ACCESS_KEY_ID=test
+export AWS_SECRET_ACCESS_KEY=test
 pytest tests/test_infra.py
 ```
 
@@ -170,8 +173,8 @@ Use the LocalStack Web Application to inspect your deployed resources:
 Skip the deployment step by loading a pre-configured environment:
 
 ```bash
-localstack restart
-localstack pod load serverless-quiz-app
+lstk restart
+lstk snapshot load pod:serverless-quiz-app
 ```
 
 This instantly loads the complete application infrastructure from a saved state.

From b57547623ed91e543d070f94148a244321033dd1 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Mon, 17 Aug 2026 09:43:42 +1200
Subject: [PATCH 03/18] Convert aws-proxy-localstack-extension page.

---
 .../aws-proxy-localstack-extension.mdx        | 44 ++++++-------------
 1 file changed, 14 insertions(+), 30 deletions(-)

diff --git a/src/content/docs/aws/tutorials/aws-proxy-localstack-extension.mdx b/src/content/docs/aws/tutorials/aws-proxy-localstack-extension.mdx
index 43f31210..792362ec 100644
--- a/src/content/docs/aws/tutorials/aws-proxy-localstack-extension.mdx
+++ b/src/content/docs/aws/tutorials/aws-proxy-localstack-extension.mdx
@@ -7,7 +7,7 @@ services:
 platform:
 - Python
 deployment:
-- awscli
+- lstk aws
 pro: true
 leadimage: "aws-proxy-extension-tutorial-cover.png"
 ---
@@ -29,9 +29,9 @@ In this tutorial, you will learn how to install the AWS Cloud Proxy extension an
 
 ## Prerequisites
 
-- [LocalStack CLI](/aws/getting-started/installation#localstack-cli)  with  [`LOCALSTACK_AUTH_TOKEN`](/aws/getting-started/auth-token)
+- [`lstk`](/aws/getting-started/installation#lstk)  with  [`LOCALSTACK_AUTH_TOKEN`](/aws/getting-started/auth-token)
 - [Docker](https://docs.docker.com/)
-- [AWS CLI](https://docs.aws.amazon.com/cli/v1/userguide/cli-chap-install.html) with  [`awslocal` wrapper](https://github.com/localstack/awscli-local)
+- [AWS CLI](https://docs.aws.amazon.com/cli/v1/userguide/cli-chap-install.html) with  [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws)
 - [LocalStack account](https://www.localstack.cloud/pricing)
 - [AWS Account](https://aws.amazon.com/) with an [`AWS_ACCESS_KEY_ID` & `AWS_SECRET_ACCESS_KEY`](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)
 
@@ -39,29 +39,13 @@ In this tutorial, you will learn how to install the AWS Cloud Proxy extension an
 
 To install the AWS Cloud Proxy Extension, follow these steps:
 
-1. Launch your LocalStack container using the `localstack` CLI, ensuring that `LOCALSTACK_AUTH_TOKEN` is available in the environment.
+1. Launch your LocalStack container using the `lstk` CLI, ensuring that `LOCALSTACK_AUTH_TOKEN` is available in the environment.
 2. Visit the [Extensions library](https://app.localstack.cloud/extensions/library) page on the LocalStack Web Application.
   ![Extensions Library](/images/aws/aws-proxy-tutorial/extensions-library.png)
 3. Scroll down to find the **AWS Cloud Proxy** card, then click on the **Install on Instance** button.
   ![Installing AWS Cloud Proxy extension](/images/aws/aws-proxy-tutorial/installing-aws-proxy-extensions.png)
 
 Once the installation is complete, you will notice that your LocalStack container has restarted with the AWS Cloud Proxy extension successfully installed.
-To confirm the installation, execute the following command:
-
-```bash
-localstack extensions list
-```
-
-```bash title="Output"
-┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┓
-┃ Name                         ┃ Summary                      ┃ Version ┃ Author          ┃ Plugin name    ┃
-┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━┩
-│ localstack-extension-aws-re… │ LocalStack Extension: AWS    │ 0.1.11  │ LocalStack Team │ aws-proxy      │
-│                              │ Cloud Proxy                  │         │                 │                │
-└──────────────────────────────┴──────────────────────────────┴─────────┴─────────────────┴────────────────┘
-```
-
-After verifying the successful installation, you can shut down the LocalStack container to re-start it with additional configuration variables.
 
 ## Tutorial: Working with the AWS Cloud Proxy Extension
 
@@ -83,15 +67,15 @@ In the following sections, you will create the SQS queue on your local machine a
 Begin by running your LocalStack container with the following configuration:
 
 ```bash
-EXTRA_CORS_ALLOWED_ORIGINS=https://aws-proxy.localhost.localstack.cloud:4566 \
-DEBUG=1 \
-localstack start
+LOCALSTACK_EXTRA_CORS_ALLOWED_ORIGINS=https://aws-proxy.localhost.localstack.cloud:4566 \
+LOCALSTACK_DEBUG=1 \
+lstk start
 ```
 
 In the above command:
 
-- The `EXTRA_CORS_ALLOWED_ORIGINS` variable allows the AWS Cloud Proxy extension's web interface to connect with the LocalStack container.
-- The `DEBUG` variable enables verbose logging allowing you to see the printed statements from the Lambda function.
+- The `LOCALSTACK_EXTRA_CORS_ALLOWED_ORIGINS` variable allows the AWS Cloud Proxy extension's web interface to connect with the LocalStack container.
+- The `LOCALSTACK_DEBUG` variable enables verbose logging allowing you to see the printed statements from the Lambda function.
 
 Next, create a file named `testlambda.py` and add the following Python code to it:
 
@@ -104,7 +88,7 @@ Execute the following commands to create the local Lambda function:
 
 ```bash
 (zip testlambda.zip testlambda.py)
-awslocal lambda create-function \
+lstk aws lambda create-function \
     --function-name func1 \
     --runtime python3.8 \
     --role arn:aws:iam::000000000000:role/r1 --handler testlambda.handler \
@@ -129,7 +113,7 @@ awslocal lambda create-function \
 You can create the local SQS queue named `test-queue` by executing the following command:
 
 ```bash
-awslocal sqs create-queue --queue-name test-queue
+lstk aws sqs create-queue --queue-name test-queue
 ```
 
 ```bash title="Output"
@@ -152,7 +136,7 @@ Before invoking, set up an event source mapping between the SQS queue and the La
 Configure the queue for Lambda using the following command:
 
 ```bash
-awslocal lambda create-event-source-mapping \
+lstk aws lambda create-event-source-mapping \
     --function-name func1 \
     --batch-size 1 \
     --event-source-arn arn:aws:sqs:us-east-1:000000000000:test-queue
@@ -172,7 +156,7 @@ awslocal lambda create-event-source-mapping \
 You can then send a message to the SQS queue to trigger the local Lambda function:
 
 ```bash
-awslocal sqs send-message \
+lstk aws sqs send-message \
     --queue-url http://sqs.us-east-1.localhost.localstack.cloud:4566/000000000000/test-queue \
     --message-body '{}'
 ```
@@ -227,7 +211,7 @@ You will observe the local Lambda function being invoked once again, with corres
 2024-03-26T07:45:16.524 DEBUG --- [db58fad602e5] l.s.l.i.version_manager    : [func1-ed938bb0-e1ee-41fb-a844-db58fad602e5] END RequestId: ed938bb0-e1ee-41fb-a844-db58fad602e5
 ```
 
-You can even run the standard `awslocal` commands in your terminal that would query the remote cloud resources, instead of the local ones.
+You can even run the standard `lstk aws` commands in your terminal that would query the remote cloud resources, instead of the local ones.
 
 Upon completion, you can click **Disable** on the AWS Cloud Proxy extension web interface to deactivate the proxy configuration.
 Additionally, you can delete the remote SQS queue to avoid AWS billing for long-running resources.

From 962a1e9f443e626527167b7f7463403409176ef3 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Mon, 17 Aug 2026 09:54:15 +1200
Subject: [PATCH 04/18] Additional fix to serverless-quiz-app

---
 src/content/docs/aws/tutorials/serverless-quiz-app.mdx | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/content/docs/aws/tutorials/serverless-quiz-app.mdx b/src/content/docs/aws/tutorials/serverless-quiz-app.mdx
index 60b26c7c..da52497b 100644
--- a/src/content/docs/aws/tutorials/serverless-quiz-app.mdx
+++ b/src/content/docs/aws/tutorials/serverless-quiz-app.mdx
@@ -109,7 +109,6 @@ bin/deploy.sh
 
 Alternatively, deploy using AWS CDK with LocalStack:
 
-{/* lstk migration: this script (in the external sample repo) takes the wrapper binary as a single-word env var (AWS_CMD/CDK_CMD) — `lstk aws`/`lstk cdk` are two-word invocations that may not work as a drop-in value depending on how deploy_cdk.sh invokes them. Review the script before relying on this */}
 ```bash
 cd cdk
 lstk cdk bootstrap

From aae4be6391fd5af6f933fd72980c185b99b79fb6 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Mon, 17 Aug 2026 10:03:38 +1200
Subject: [PATCH 05/18] Convert s3-static-website-terraform

---
 .../tutorials/s3-static-website-terraform.mdx | 38 +++++++++----------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/src/content/docs/aws/tutorials/s3-static-website-terraform.mdx b/src/content/docs/aws/tutorials/s3-static-website-terraform.mdx
index c0fc0167..29182804 100644
--- a/src/content/docs/aws/tutorials/s3-static-website-terraform.mdx
+++ b/src/content/docs/aws/tutorials/s3-static-website-terraform.mdx
@@ -1,7 +1,7 @@
 ---
 title: "Host a static website locally using Simple Storage Service (S3) and Terraform with LocalStack"
 description: >
-  Host a static website using a Simple Storage Service (S3) bucket to serve static content by provisioning the infrastructure using Terraform in LocalStack. Learn how to configure S3 buckets locally for testing and integration, and make use of LocalStack's S3 API & `tflocal` CLI to provision infrastructure locally.
+  Host a static website using a Simple Storage Service (S3) bucket to serve static content by provisioning the infrastructure using Terraform in LocalStack. Learn how to configure S3 buckets locally for testing and integration, and make use of LocalStack's S3 API & `lstk terraform` CLI to provision infrastructure locally.
 services:
 - s3
 platform:
@@ -26,15 +26,15 @@ LocalStack also supports the creation of S3 buckets with static website hosting
 
 In this tutorial, we will deploy a static website using an S3 bucket over a locally emulated AWS infrastructure on LocalStack.
 We will use Terraform to automate the creation & management of AWS resources by declaring them in the HashiCorp Configuration Language (HCL).
-We will also learn about `tflocal`, a CLI wrapper created by LocalStack, that allows you to run Terraform locally against LocalStack.
+We will also learn about `lstk terraform`, part of the `lstk` CLI, that allows you to run Terraform locally against LocalStack.
 
 ## Prerequisites
 
 For this tutorial, you will need:
 
-- [LocalStack for AWS](https://hub.docker.com/r/localstack/localstack)
+- [LocalStack for AWS](https://www.localstack.cloud/localstack-for-aws)
 - [Terraform](https://www.terraform.io/downloads.html)
-- [awslocal](https://github.com/localstack/awscli-local)
+- [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws)
 
 ## Architecture
 
@@ -97,16 +97,16 @@ Create a file named `error.html` next to `index.html` inside `www/` and add the
 S3 will return the above file content only for HTTP 4XX error codes.
 Some browsers might choose to display their custom error message if a user tries to access a resource that does not exist.
 In this case, browsers might ignore the above error document.
-With the initial setup complete, we can now move on to creating a static website using S3 via `awslocal`, LocalStack's wrapper for the AWS CLI.
+With the initial setup complete, we can now move on to creating a static website using S3 via `lstk aws`, LocalStack's wrapper for the AWS CLI.
 
 ## Hosting a static website using S3
 
 To create a static website using S3, we need to create a bucket, enable static website hosting, and upload the files to the bucket.
-We will use the `awslocal` CLI for these operations.
+We will use the `lstk aws` CLI for these operations.
 Navigate to the root directory of the project and create a bucket named `testwebsite` using LocalStack's S3 API:
 
 ```bash
-awslocal s3api create-bucket --bucket testwebsite
+lstk aws s3api create-bucket --bucket testwebsite
 ```
 
 With the bucket created, we can now attach a policy to it to allow public access and its contents.
@@ -130,19 +130,19 @@ Let's create a file named `bucket_policy.json` in the project root (next to the
 Let's now attach the policy to the bucket:
 
 ```bash
-awslocal s3api put-bucket-policy --bucket testwebsite --policy file://bucket_policy.json
+lstk aws s3api put-bucket-policy --bucket testwebsite --policy file://bucket_policy.json
 ```
 
 With the policy attached, we can now sync the contents of our `www/` directory to the bucket:
 
 ```bash
-awslocal s3 sync ./www/ s3://testwebsite
+lstk aws s3 sync ./www/ s3://testwebsite
 ```
 
 We'll now enable static website hosting on the bucket and configure the index and error documents:
 
 ```bash
-awslocal s3 website s3://testwebsite/ --index-document index.html --error-document error.html
+lstk aws s3 website s3://testwebsite/ --index-document index.html --error-document error.html
 ```
 
 If you are deploying a static website using S3 on real AWS cloud, your S3 website endpoint will follow one of these two formats:
@@ -366,19 +366,19 @@ name = "testwebsite"
 website_endpoint = "http://testwebsite.s3-website.localhost.localstack.cloud:4566"
 ```
 
-In the above command, we specified `testwebsite` as the bucket name to keep it consistent with the `awslocal` flow above and the testing commands further down.
+In the above command, we specified `testwebsite` as the bucket name to keep it consistent with the `lstk aws` flow above and the testing commands further down.
 You can specify any bucket name since LocalStack is ephemeral, and stopping your LocalStack container will delete all the created resources.
 The above command output includes the ARN, name, LocalStack website domain, and the website endpoint URL of the bucket.
 You can navigate directly to the printed `website_endpoint` to view your site, since the endpoint uses `localhost.localstack.cloud`, no real AWS resources have been created.
 
-You can optionally use the `tflocal` CLI as a drop-in replacement for the official Terraform CLI. `tflocal` uses the Terraform Override mechanism to create a temporary `localstack_providers_override.tf` file, which is deleted after the infrastructure is created.
+You can optionally use the `lstk terraform` command as a drop-in replacement for the official Terraform CLI. `lstk terraform` uses the Terraform Override mechanism to create a temporary `localstack_providers_override.tf` file, which is deleted after the infrastructure is created.
 It mitigates the need to create the `provider.tf` file manually.
-You can use `tflocal` to create the infrastructure by running the following commands:
+You can use `lstk terraform` to create the infrastructure by running the following commands:
 
 ```bash
-tflocal init
-tflocal plan
-tflocal apply
+lstk terraform init
+lstk terraform plan
+lstk terraform apply
 ```
 
 ## Testing the application
@@ -418,10 +418,10 @@ You should receive the content from your `error.html` file: "Something is amiss.
 
 ### Checking bucket configuration
 
-You can verify the bucket's website configuration using `awslocal`:
+You can verify the bucket's website configuration using `lstk aws`:
 
 ```bash
-awslocal s3api get-bucket-website --bucket testwebsite
+lstk aws s3api get-bucket-website --bucket testwebsite
 ```
 
 This command should return the index and error document configuration for your bucket.
@@ -431,7 +431,7 @@ This command should return the index and error document configuration for your b
 To confirm all your files were uploaded correctly:
 
 ```bash
-awslocal s3 ls s3://testwebsite/
+lstk aws s3 ls s3://testwebsite/
 ```
 
 This will display all the files in your bucket, including `index.html`, `error.html`, and any additional assets.

From 1f33d3ecf60285a8b26cb77d109249ded6f24bd8 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Mon, 17 Aug 2026 10:13:47 +1200
Subject: [PATCH 06/18] Convert rds-database-initialization.

---
 .../tutorials/rds-database-initialization.mdx | 25 +++++++++----------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/src/content/docs/aws/tutorials/rds-database-initialization.mdx b/src/content/docs/aws/tutorials/rds-database-initialization.mdx
index 32975645..ec306468 100644
--- a/src/content/docs/aws/tutorials/rds-database-initialization.mdx
+++ b/src/content/docs/aws/tutorials/rds-database-initialization.mdx
@@ -28,8 +28,8 @@ In this tutorial, we will demonstrate how to provision and initialize an Amazon
 For this tutorial, you will need:
 
 - [LocalStack for AWS](https://localstack.cloud/pricing/) with a valid auth token
-- [AWS CLI](https://docs.localstack.cloud/user-guide/integrations/aws-cli/) with the [`awslocal` wrapper](https://docs.localstack.cloud/user-guide/integrations/aws-cli/#localstack-aws-cli-awslocal)
-- [AWS CDK](https://docs.localstack.cloud/user-guide/integrations/aws-cdk/) with the [`cdklocal`](https://www.npmjs.com/package/aws-cdk-local) wrapper
+- [AWS CLI](https://docs.localstack.cloud/user-guide/integrations/aws-cli/) with the [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws) command
+- [AWS CDK](https://docs.localstack.cloud/user-guide/integrations/aws-cdk/) with the [`lstk cdk`](/aws/connecting/infrastructure-as-code/aws-cdk#aws-cdk-cli-for-localstack) command
 - [Node.js](https://nodejs.org/en/download/) (version 16 or later)
 - [Docker](https://docker.io/)
 - MySQL or PostgreSQL client (for testing database connections)
@@ -79,8 +79,7 @@ make install
 Start LocalStack with your auth token:
 
 ```bash
-localstack auth set-token <your-auth-token>
-localstack start
+lstk start
 ```
 
 > **Note**: By default, LocalStack uses the MariaDB engine for RDS (see [RDS documentation](https://docs.localstack.cloud/user-guide/aws/rds/#mysql-engine)). To use the real MySQL engine in a separate Docker container, set the environment variable `RDS_MYSQL_DOCKER=1`.
@@ -92,7 +91,7 @@ Deploy the sample application using CDK:
 ```bash
 make deploy
 # or manually:
-cdklocal deploy
+lstk cdk deploy
 ```
 
 The deployment process will:
@@ -133,7 +132,7 @@ The deployed Lambda function `my-lambda-rds-query-helper` can execute SQL querie
 
 **For AWS CLI v1:**
 ```bash
-awslocal lambda invoke \
+lstk aws lambda invoke \
   --function-name my-lambda-rds-query-helper \
   --payload '{"sqlQuery": "select Author from books", "secretName":"/rdsinitexample/rds/creds/mysql-01"}' \
   output
@@ -141,7 +140,7 @@ awslocal lambda invoke \
 
 **For AWS CLI v2:**
 ```bash
-awslocal lambda invoke \
+lstk aws lambda invoke \
   --cli-binary-format raw-in-base64-out \
   --function-name my-lambda-rds-query-helper \
   --payload '{"sqlQuery": "select Author from books", "secretName":"/rdsinitexample/rds/creds/mysql-01"}' \
@@ -169,7 +168,7 @@ You can also run more detailed queries to explore the data:
 
 **Query all book details:**
 ```bash
-awslocal lambda invoke \
+lstk aws lambda invoke \
   --cli-binary-format raw-in-base64-out \
   --function-name my-lambda-rds-query-helper \
   --payload '{"sqlQuery": "SELECT * FROM books LIMIT 5", "secretName":"/rdsinitexample/rds/creds/mysql-01"}' \
@@ -182,7 +181,7 @@ Test various database operations to verify the initialization:
 
 **Check table structure:**
 ```bash
-awslocal lambda invoke \
+lstk aws lambda invoke \
   --cli-binary-format raw-in-base64-out \
   --function-name my-lambda-rds-query-helper \
   --payload '{"sqlQuery": "DESCRIBE books", "secretName":"/rdsinitexample/rds/creds/mysql-01"}' \
@@ -191,7 +190,7 @@ awslocal lambda invoke \
 
 **Count records:**
 ```bash
-awslocal lambda invoke \
+lstk aws lambda invoke \
   --cli-binary-format raw-in-base64-out \
   --function-name my-lambda-rds-query-helper \
   --payload '{"sqlQuery": "SELECT COUNT(*) as total_books FROM books", "secretName":"/rdsinitexample/rds/creds/mysql-01"}' \
@@ -200,7 +199,7 @@ awslocal lambda invoke \
 
 **Filter by author:**
 ```bash
-awslocal lambda invoke \
+lstk aws lambda invoke \
   --cli-binary-format raw-in-base64-out \
   --function-name my-lambda-rds-query-helper \
   --payload '{"sqlQuery": "SELECT title, published_year FROM books WHERE author = \"George Orwell\"", "secretName":"/rdsinitexample/rds/creds/mysql-01"}' \
@@ -213,10 +212,10 @@ For more comprehensive testing, you can connect directly to the RDS instance usi
 
 ```bash
 # Get the database endpoint
-awslocal rds describe-db-instances --query 'DBInstances[0].Endpoint.Address' --output text
+lstk aws rds describe-db-instances --query 'DBInstances[0].Endpoint.Address' --output text
 
 # Get credentials from Secrets Manager
-awslocal secretsmanager get-secret-value --secret-id /rdsinitexample/rds/creds/mysql-01 --query SecretString --output text
+lstk aws secretsmanager get-secret-value --secret-id /rdsinitexample/rds/creds/mysql-01 --query SecretString --output text
 ```
 
 Connect using the MySQL command-line client:

From ab7acc29a9d5ae7e0947d6a905354c86f7834270 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Mon, 17 Aug 2026 10:30:24 +1200
Subject: [PATCH 07/18] Convert elb-load-balancing

---
 .../docs/aws/tutorials/elb-load-balancing.mdx    | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/content/docs/aws/tutorials/elb-load-balancing.mdx b/src/content/docs/aws/tutorials/elb-load-balancing.mdx
index 801c7038..f54d3c27 100644
--- a/src/content/docs/aws/tutorials/elb-load-balancing.mdx
+++ b/src/content/docs/aws/tutorials/elb-load-balancing.mdx
@@ -38,7 +38,7 @@ Additionally, we will demonstrate how to set up ELB endpoints to efficiently for
 - LocalStack for AWS
 - [Serverless framework](https://www.serverless.com/framework/docs/getting-started/)
 - [Node.js & `npm`](https://nodejs.org/en/download/)
-- [awslocal](https://github.com/localstack/awscli-local)
+- [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws)
 - [curl](https://curl.se/) and [jq](https://jqlang.github.io/jq/)
 
 ## Architecture
@@ -306,7 +306,7 @@ Now that we have completed the initial setup, let's run LocalStack's AWS emulati
 Start LocalStack by running the following command:
 
 ```bash
-LOCALSTACK_AUTH_TOKEN=<your-auth-token> localstack start -d
+lstk start
 ```
 
 This command launches LocalStack in the background, enabling you to use the AWS services locally. Now, let's deploy our Serverless project and verify the resources created in LocalStack.
@@ -344,7 +344,7 @@ This output confirms the successful deployment of your Serverless service to the
 You can run the following command to verify that the functions and the load balancers have been deployed:
 
 ```bash showLineNumbers
-awslocal lambda list-functions
+lstk aws lambda list-functions
 {
     "Functions": [
         {
@@ -366,7 +366,7 @@ awslocal lambda list-functions
     ]
 }
 
-awslocal elbv2 describe-load-balancers
+lstk aws elbv2 describe-load-balancers
 {
     "LoadBalancers": [
         {
@@ -391,7 +391,7 @@ The ALB endpoints for the two Lambda functions, hello1 and hello2, are accessibl
 
 Here in the testing phase we will test endpoints, do a validation check which includes health check and error handling. To test these endpoints, you can use the curl command along with the jq tool for better formatting.
 
-1. **Verify Deployment:** Use the commands `awslocal lambda list-functions` and `awslocal elbv2 describe-load-balancers` respectively to confirm the existince of Lambda and ALB respectively
+1. **Verify Deployment:** Use the commands `lstk aws lambda list-functions` and `lstk aws elbv2 describe-load-balancers` respectively to confirm the existince of Lambda and ALB respectively
 2. **Test Endpoints:** Run the following commands:
 
 ```bash
@@ -404,7 +404,7 @@ Both commands send an HTTP GET request to the endpoints and uses `jq` to format
 
 3. **Health Checks:** Describe target health:
 ```bash
-awslocal elbv2 describe-target-health --target-group-arn $(awslocal elbv2 describe-target-groups --load-balancer-arn $(awslocal elbv2 describe-load-balancers --names lb-test-1 --query 'LoadBalancers[0].LoadBalancerArn' --output text) --query 'TargetGroups[0].TargetGroupArn' --output text)
+lstk aws elbv2 describe-target-health --target-group-arn $(lstk aws elbv2 describe-target-groups --load-balancer-arn $(lstk aws elbv2 describe-load-balancers --names lb-test-1 --query 'LoadBalancers[0].LoadBalancerArn' --output text) --query 'TargetGroups[0].TargetGroupArn' --output text)
 ```
 
 4. **Invalid Path:** Test fallback/redirect:
@@ -414,10 +414,10 @@ curl -I http://lb-test-1.elb.localhost.localstack.cloud:4566/invalid
 
 5. **Logs Validation:** Check Lambda logs for invocations:
 ```bash
-awslocal logs describe-log-groups --query 'logGroups[].logGroupName' | jq -r '.[] | select(contains("hello1"))' | xargs -I {} awslocal logs tail {} --follow
+lstk aws logs describe-log-groups --query 'logGroups[].logGroupName' | jq -r '.[] | select(contains("hello1"))' | xargs -I {} lstk aws logs tail {} --follow
 ```
 
-If tests fail, you can ensure LocalStack is healthy (`localstack status services`), check ports (default `4566`), and restart if needed.
+If tests fail, you can ensure LocalStack is healthy (`lstk status`), check ports (default `4566`), and restart if needed.
 
 ## Conclusion
 

From 6562d1b4529afbe0699c39bf5123d8e0b9ea0ecc Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Tue, 18 Aug 2026 06:40:11 +1200
Subject: [PATCH 08/18] Convert schema-evolution-glue

---
 .../tutorials/schema-evolution-glue-msk.mdx   | 131 ++----------------
 1 file changed, 8 insertions(+), 123 deletions(-)

diff --git a/src/content/docs/aws/tutorials/schema-evolution-glue-msk.mdx b/src/content/docs/aws/tutorials/schema-evolution-glue-msk.mdx
index c6881a84..becec57c 100644
--- a/src/content/docs/aws/tutorials/schema-evolution-glue-msk.mdx
+++ b/src/content/docs/aws/tutorials/schema-evolution-glue-msk.mdx
@@ -53,7 +53,7 @@ For this tutorial you will need:
 
 - [LocalStack for AWS](https://localstack.cloud/pricing/) to emulate Amazon MSK and AWS Glue Schema Registry locally
   - Don't worry, if you don't have a subscription yet, you can just get a trial license for free.
-- [awslocal](/aws/connecting/aws-cli#localstack-aws-cli-awslocal)
+- [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws)
 - Java 11+
 - Maven 3
 
@@ -590,13 +590,13 @@ Now that the initial coding is done, we can give it a try.
 Let's start LocalStack:
 
 ```bash
-LOCALSTACK_AUTH_TOKEN=<your-auth-token> localstack start -d
+lstk start
 ```
 
-Once LocalStack is started, we can create a new Kafka cluster using `awslocal`:
+Once LocalStack is started, we can create a new Kafka cluster using `lstk aws`:
 
 ```bash
-awslocal kafka create-cluster \
+lstk aws kafka create-cluster \
   --cluster-name "unicorn-ride-cluster" \
   --kafka-version "2.2.1" \
   --number-of-broker-nodes 1 \
@@ -618,7 +618,7 @@ It takes some time for the cluster to get up and running.
 We can monitor the state with `describe-cluster`:
 
 ```bash
-awslocal kafka describe-cluster --cluster-arn "arn:aws:kafka:us-east-1:000000000000:cluster/unicorn-ride-cluster/f9b16124-baf3-459b-8507-ec6c605b7a0a-25"
+lstk aws kafka describe-cluster --cluster-arn "arn:aws:kafka:us-east-1:000000000000:cluster/unicorn-ride-cluster/f9b16124-baf3-459b-8507-ec6c605b7a0a-25"
 ```
 
 ```bash title="Output"
@@ -646,7 +646,7 @@ Once the `State` is `ACTIVE`, the cluster is ready to be used.
 Now it's time to create our Glue Schema Registry:
 
 ```bash
-awslocal glue create-registry --registry-name unicorn-ride-request-registry
+lstk aws glue create-registry --registry-name unicorn-ride-request-registry
 ```
 
 ```bash title="Output"
@@ -659,7 +659,7 @@ awslocal glue create-registry --registry-name unicorn-ride-request-registry
 In the newly created registry, we can now add our initial `UnicornRideRequest` schema:
 
 ```bash
-awslocal glue create-schema \
+lstk aws glue create-schema \
   --registry-id RegistryName="unicorn-ride-request-registry" \
   --schema-name unicorn-ride-request-schema-avro \
   --compatibility BACKWARD \
@@ -697,7 +697,7 @@ Finally, everything is ready to start our `Producer` and `Consumer`.
 First, we need to get the bootstrap server address from the Kafka cluster:
 
 ```bash
-awslocal kafka get-bootstrap-brokers --cluster-arn  "arn:aws:kafka:us-east-1:000000000000:cluster/unicorn-ride-cluster/f9b16124-baf3-459b-8507-ec6c605b7a0a-25"
+lstk aws kafka get-bootstrap-brokers --cluster-arn  "arn:aws:kafka:us-east-1:000000000000:cluster/unicorn-ride-cluster/f9b16124-baf3-459b-8507-ec6c605b7a0a-25"
 ```
 
 ```bash title="Output"
@@ -1051,122 +1051,7 @@ Our new consumer, based on the latest version of the schema, will be able to suc
 ```bash
 mvn -pl consumer-2 exec:java -Dexec.args="--bootstrap-servers localhost:4511"
 ```
-## Testing the application
 
-After deploying and running the example, you can verify that your MSK and Glue Schema Registry integration is functioning correctly.  
-This section consolidates the end-to-end verification steps — producing and consuming messages, and validating schema compatibility.
-
----
-
-### 1. Produce a message to the Kafka topic
-
-Use the `awslocal` CLI or your preferred Kafka client to produce a test message using the initial Avro schema:
-
-```bash
-awslocal kafka-produce \
-  --topic my-topic \
-  --value '{"name": "Alice", "age": 30}'
-```
-Expected output:
-
-Message successfully produced to topic 'my-topic'
-
-
-This message is serialized using the Avro schema registered in the Glue Schema Registry.
-
-### 2. Consume and verify the message
-
-Consume from the same topic using a compatible schema:
-```
-awslocal kafka-consume \
-  --topic my-topic \
-  --from-beginning \
-  --max-messages 1
-```
-
-Expected output:
-```
-{"name": "Alice", "age": 30}
-```
-
-This confirms that your consumer can successfully deserialize messages using the registered schema version.
-
-### 3. Test schema evolution and compatibility
-
-Now modify your Avro schema to simulate an update (for example, adding a new optional field):
-```
-{
-  "type": "record",
-  "name": "User",
-  "fields": [
-    { "name": "name", "type": "string" },
-    { "name": "age", "type": "int" },
-    { "name": "email", "type": ["null", "string"], "default": null }
-  ]
-}
-```
-Register the updated schema version:
-```
-awslocal glue register-schema-version \
-  --schema-id SchemaName=my-schema \
-  --schema-definition file://updated_user_schema.avsc
-```
-Expected output:
-```
-{
-  "SchemaVersionId": "abcd1234...",
-  "Status": "AVAILABLE"
-}
-```
-Then verify schema compatibility:
-```
-awslocal glue check-schema-compatibility \
-  --schema-id SchemaName=my-schema \
-  --data-format AVRO \
-  --schema-definition file://updated_user_schema.avsc
-```
-Expected output:
-```
-{
-  "Compatibility": "COMPATIBLE"
-}
-```
-This indicates that the updated schema maintains backward compatibility with existing data.
-
-4. Validate end-to-end flow after schema update
-
-Produce a message using the new schema:
-```
-awslocal kafka-produce \
-  --topic my-topic \
-  --value '{"name": "Bob", "age": 25, "email": "bob@example.com"}'
-```
-
-Then consume again to verify successful deserialization:
-```
-awslocal kafka-consume \
-  --topic my-topic \
-  --from-beginning \
-  --max-messages 2
-```
-
-Expected output:
-```
-{"name": "Alice", "age": 30}
-{"name": "Bob", "age": 25, "email": "bob@example.com"}
-```
-
-Both messages deserialize successfully, confirming that schema evolution and compatibility are functioning as expected.
-
-### 5. Summary
-
-You’ve validated that:
-
-* Kafka topics in LocalStack correctly trigger message serialization/deserialization through Glue Schema Registry.
-
-* Schema evolution (adding optional fields) preserves backward compatibility.
-
-* Both producer and consumer integrate seamlessly after schema updates.
 ## Conclusion
 
 Apache Kafka is used as the core messaging system in complex environments, with independent producers and consumers.

From 90e35d210a4e12ed901af612cc1494d617fc38da Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Tue, 18 Aug 2026 07:19:15 +1200
Subject: [PATCH 09/18] Convert ecs-ecr-container

---
 .../aws/tutorials/ecs-ecr-container-app.mdx   | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/src/content/docs/aws/tutorials/ecs-ecr-container-app.mdx b/src/content/docs/aws/tutorials/ecs-ecr-container-app.mdx
index a31c75ba..437bf8a7 100644
--- a/src/content/docs/aws/tutorials/ecs-ecr-container-app.mdx
+++ b/src/content/docs/aws/tutorials/ecs-ecr-container-app.mdx
@@ -1,6 +1,6 @@
 ---
 title: "Deploying containers on Elastic Container Service (ECS) clusters using Elastic Container Registry (ECR) and AWS Fargate, with LocalStack"
-description: Set up an NGINX web server via Elastic Container Service (ECS) and Elastic Container Registry (ECR) to serve a static website using LocalStack. Learn how you can use CloudFormation templates to declaratively define, create, and deploy your architecture locally with LocalStack's `awslocal` CLI.
+description: Set up an NGINX web server via Elastic Container Service (ECS) and Elastic Container Registry (ECR) to serve a static website using LocalStack. Learn how you can use CloudFormation templates to declaratively define, create, and deploy your architecture locally with LocalStack's `lstk aws` CLI.
 services:
 - ecs
 - ecr
@@ -26,7 +26,7 @@ This tutorial will showcase using LocalStack to set up an NGINX web server to se
 ## Prerequisites
 
 - [LocalStack for AWS](https://localstack.cloud/pricing/)
-- [awslocal](/aws/connecting/aws-cli#localstack-aws-cli-awslocal)
+- [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws)
 - [Docker](https://docker.io/)
 - [curl](https://curl.se/download.html)
 
@@ -43,17 +43,17 @@ ENV foo=bar
 
 The `Dockerfile` uses the official `nginx` image from Docker Hub, which allows us to serve the default index page.
 Before building our Docker image, we need to start LocalStack and create an ECR repository to push our Docker image.
-To start LocalStack with the `LOCALSTACK_AUTH_TOKEN` environment variable, run the following command:
+To start LocalStack, run the following command:
 
 ```bash
-LOCALSTACK_AUTH_TOKEN=<your-auth-token> localstack start -d
+lstk start
 ```
 
 Next, we will create an ECR repository to push our Docker image.
-We will use the `awslocal` CLI to create the repository.
+We will use the `lstk aws` CLI to create the repository.
 
 ```bash
-awslocal ecr create-repository --repository-name sample-ecr-repo
+lstk aws ecr create-repository --repository-name sample-ecr-repo
 ```
 
 The output of this command will contain the `repositoryUri` value that we'll need in the next step:
@@ -360,13 +360,13 @@ Outputs:
 To deploy the CloudFormation template we created earlier, use the following command:
 
 ```bash
-awslocal cloudformation create-stack --stack-name infra --template-body file://templates/ecs.infra.yml
+lstk aws cloudformation create-stack --stack-name infra --template-body file://templates/ecs.infra.yml
 ```
 
 Wait until the stack status changes to `CREATE_COMPLETE` by running the following command:
 
 ```bash
-awslocal cloudformation wait stack-create-complete --stack-name infra
+lstk aws cloudformation wait stack-create-complete --stack-name infra
 ```
 
 You can also check your deployed stack on the LocalStack Web Application by navigating to the [CloudFormation resource browser](https://app.localstack.cloud/resources/cloudformation/stacks).
@@ -535,28 +535,28 @@ Resources:
 Next, let's deploy the CloudFormation template by running the following command:
 
 ```bash
-awslocal cloudformation create-stack --stack-name ecs --template-body file://templates/ecs.sample.yml --parameters ParameterKey=ImageUrl,ParameterValue=<REPOSITORY_URI>
+lstk aws cloudformation create-stack --stack-name ecs --template-body file://templates/ecs.sample.yml --parameters ParameterKey=ImageUrl,ParameterValue=<REPOSITORY_URI>
 ```
 
 Replace `<REPOSITORY_URI>` with the URI of the Docker image that you want to deploy.
 Wait for the stack to be created by running the following command:
 
 ```bash
-awslocal cloudformation wait stack-create-complete --stack-name ecs
+lstk aws cloudformation wait stack-create-complete --stack-name ecs
 ```
 
 Now that the ECS service has been deployed successfully, let's access the application endpoint.
 First, let's list all the ECS clusters we have deployed in our local environment by running the following command to retrieve the cluster ARN:
 
 ```bash
-awslocal ecs list-clusters | jq -r '.clusterArns[0]'
+lstk aws ecs list-clusters | jq -r '.clusterArns[0]'
 ```
 
 Save the output of the above command as `CLUSTER_ARN`, as we will use it to list the tasks running in the cluster.
 Next, run the following command to list the task ARN:
 
 ```bash
-awslocal ecs list-tasks --cluster <CLUSTER_ARN> | jq -r '.taskArns[0]'
+lstk aws ecs list-tasks --cluster <CLUSTER_ARN> | jq -r '.taskArns[0]'
 ```
 
 Save the task ARN as `TASK_ARN`.
@@ -564,7 +564,7 @@ Let us now list the port number on which the application is running.
 Run the following command:
 
 ```bash
-awslocal ecs describe-tasks --cluster <CLUSTER_ARN> --tasks <TASK_ARN> | jq -r '.tasks[0].containers[0].networkBindings[0].hostPort'
+lstk aws ecs describe-tasks --cluster <CLUSTER_ARN> --tasks <TASK_ARN> | jq -r '.tasks[0].containers[0].networkBindings[0].hostPort'
 ```
 
 Earlier, we configured the application to run on port `45139`, in our `HostPort` parameter.
@@ -581,7 +581,7 @@ You should see the default index page of the NGINX web server.
 ## Conclusion
 
 In this tutorial, we have demonstrated how to deploy a containerized service locally using Amazon ECS, ECR, and LocalStack.
-We have also shown how you can use CloudFormation templates with the awslocal CLI to deploy your local AWS infrastructure.
+We have also shown how you can use CloudFormation templates with the `lstk aws` CLI to deploy your local AWS infrastructure.
 
 With LocalStack, you can easily mount code from your host filesystem into the ECS container, allowing for a quicker debugging loop that doesn't require rebuilding and redeploying the task's Docker image for each change.
 

From 6d3f2f7d9f09ebe52a66c1e9371b21225da0da1a Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Tue, 18 Aug 2026 07:29:02 +1200
Subject: [PATCH 10/18] Convert lambda-ecr-container-images

---
 .../aws/tutorials/lambda-ecr-container-images.mdx | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/src/content/docs/aws/tutorials/lambda-ecr-container-images.mdx b/src/content/docs/aws/tutorials/lambda-ecr-container-images.mdx
index cbb4af4a..197fc366 100644
--- a/src/content/docs/aws/tutorials/lambda-ecr-container-images.mdx
+++ b/src/content/docs/aws/tutorials/lambda-ecr-container-images.mdx
@@ -33,7 +33,7 @@ In this tutorial, we will explore creating a Lambda function using a container i
 Before diving into this tutorial, make sure you have the following prerequisites:
 
 - [LocalStack for AWS](https://localstack.cloud/pricing/)
-- [awslocal](/aws/connecting/aws-cli#localstack-aws-cli-awslocal)
+- [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws)
 - [Python](https://www.python.org/downloads/)
 - [Docker](https://docker.io/)
 
@@ -106,18 +106,17 @@ The resulting image will contain your function code and any specified dependenci
 
 Now that the initial setup is complete let's explore how to leverage LocalStack's AWS emulation by pushing our image to ECR and deploying the Lambda container image.
 Start LocalStack by executing the following command.
-Make sure to replace `<your-auth-token>` with your actual Auth Token:
 
 ```bash
-LOCALSTACK_AUTH_TOKEN=<your-auth-token> ECR_ENDPOINT_STRATEGY=off DEBUG=1 localstack start -d
+LOCALSTACK_ECR_ENDPOINT_STRATEGY=off LOCALSTACK_DEBUG=1 lstk start
 ```
 
 Once the LocalStack container is running, we can create a new ECR repository to store our container image.
-Use the `awslocal` CLI to achieve this.
+Use the `lstk aws` CLI to achieve this.
 Run the following command to create the repository, replacing `localstack-lambda-container-image` with the desired name for your repository:
 
 ```bash
-awslocal ecr create-repository --repository-name localstack-lambda-container-image
+lstk aws ecr create-repository --repository-name localstack-lambda-container-image
 ```
 
 ```bash title="Output"
@@ -156,7 +155,7 @@ In the above commands, we specify the `repositoryUri` as the image name to push
 After executing these commands, you can verify that the image is successfully pushed to the repository by using the `describe-images` command:
 
 ```bash
-awslocal ecr describe-images --repository-name localstack-lambda-container-image
+lstk aws ecr describe-images --repository-name localstack-lambda-container-image
 ```
 
 ```bash title="Output"
@@ -193,7 +192,7 @@ More information can be found [in our documentation regarding ARM support.](/aws
 :::
 
 ```bash
-awslocal lambda create-function \
+lstk aws lambda create-function \
     --function-name localstack-lambda-container-image \
     --package-type Image \
     --code ImageUri="localhost.localstack.cloud:4510/localstack-lambda-container-image" \
@@ -253,7 +252,7 @@ Here's an explanation of each flag:
 To invoke the Lambda function, you can use the `invoke` command:
 
 ```bash
-awslocal lambda invoke --function-name localstack-lambda-container-image /tmp/lambda.out
+lstk aws lambda invoke --function-name localstack-lambda-container-image /tmp/lambda.out
 ```
 
 ```bash title="Output"

From d365a5baa95c688c74af41d41583a03813fad645 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Tue, 18 Aug 2026 09:35:29 +1200
Subject: [PATCH 11/18] Convert terraform-shipment-app

---
 .../docs/aws/tutorials/terraform-shipment-app-guide.mdx  | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/content/docs/aws/tutorials/terraform-shipment-app-guide.mdx b/src/content/docs/aws/tutorials/terraform-shipment-app-guide.mdx
index 08ef749e..221f4fef 100644
--- a/src/content/docs/aws/tutorials/terraform-shipment-app-guide.mdx
+++ b/src/content/docs/aws/tutorials/terraform-shipment-app-guide.mdx
@@ -26,9 +26,9 @@ This sample app consists of a React frontend and a Spring Boot backend, integrat
 
 Make sure the following tools and dependencies are installed and configured on your local machine before proceeding:
 
-- **LocalStack** (preferably Team or Pro edition for advanced features)
+- **LocalStack for AWS**
 - **Terraform CLI**
-- **AWS CLI** with the [awslocal](https://docs.localstack.cloud/aws/connecting/aws-cli/#localstack-aws-cli-awslocal) wrapper for LocalStack
+- **AWS CLI** with the [`lstk aws`](https://docs.localstack.cloud/aws/connecting/aws-cli/#localstack-aws-cli-lstk-aws) command for LocalStack
 - **Maven 3.8.5+** and **Java 17** for Spring Boot backend
 - **Node.js** and **npm** for React frontend
 - **make** (optional, but recommended for simplified commands)
@@ -51,8 +51,7 @@ This command builds the Lambda validator JAR and installs frontend Node.js packa
 Start LocalStack in the background with your authorization token configured:
 
 ```
-localstack auth set-token <your-auth-token>
-localstack start -d
+lstk start
 ```
 
 Use the provided Makefile to deploy all infrastructure components:
@@ -115,7 +114,7 @@ This project illustrates:
 - Reactive messaging using SNS and SQS.
 - Seamless switching between AWS and LocalStack via Spring Profiles.
 - Integration testing using Testcontainers.
-- Using LocalStack CLI wrappers (`awslocal`, `tflocal`) for streamlined local development.
+- Using LocalStack's `lstk aws` and `lstk terraform` commands for streamlined local development.
 - Infrastructure as Code testing enabling consistent, repeatable environment setups.
 
 

From c64ce05f98fc61573a4aa155bd76221a88697716 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Tue, 18 Aug 2026 09:41:44 +1200
Subject: [PATCH 12/18] Convert java-notification-app

---
 .../docs/aws/tutorials/java-notification-app.mdx   | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/content/docs/aws/tutorials/java-notification-app.mdx b/src/content/docs/aws/tutorials/java-notification-app.mdx
index ed022d7e..1d1607a4 100644
--- a/src/content/docs/aws/tutorials/java-notification-app.mdx
+++ b/src/content/docs/aws/tutorials/java-notification-app.mdx
@@ -37,7 +37,7 @@ For this tutorial, you will need:
 
 - [LocalStack for AWS](https://localstack.cloud/pricing/) to emulate the AWS services (SNS, SQS, SES, etc) locally
   - Don't worry, if you don't have a subscription yet, you can just get a trial license for free.
-- [awslocal](/aws/connecting/aws-cli#localstack-aws-cli-awslocal)
+- [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws)
 - [Docker](https://docker.io/)
 - Java 11+
 - Maven 3+
@@ -550,10 +550,16 @@ You can start LocalStack using the following command:
 LOCALSTACK_AUTH_TOKEN=<your-auth-token> docker-compose up -d
 ```
 
+Given that you've started LocalStack via `docker-compose`, you'll need to configure the `lstk` CLI to contact your container:
+
+```bash
+export LSTK_ENDPOINT_URL=http://localhost.localstack.cloud:4566    
+```
+
 Once LocalStack is started, we can deploy the CloudFormation stack (which might take a few moments):
 
 ```bash
-awslocal cloudformation deploy \
+lstk aws cloudformation deploy \
     --template-file src/main/resources/email-infra.yml \
     --stack-name email-infra
 ```
@@ -570,13 +576,13 @@ AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test mvn spring-boot:run
 To get started, we will an add email address to the list of identities for our mocked SES account to verify the email address:
 
 ```bash
-awslocal ses verify-email-identity --email-address no-reply@localstack.cloud
+lstk aws ses verify-email-identity --email-address no-reply@localstack.cloud
 ```
 
 Let us now send a message to the topic:
 
 ```bash
-awslocal sns publish \
+lstk aws sns publish \
     --topic arn:aws:sns:us-east-1:000000000000:email-notifications \
     --message '{"subject":"hello", "address": "alice@example.com", "body": "hello world"}'
 ```

From 6dfc3b58a4995b45d73611d4506d8f53569cf374 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Tue, 18 Aug 2026 09:53:23 +1200
Subject: [PATCH 13/18] Convert ephemeral-application-previews.

---
 .../docs/aws/tutorials/ephemeral-application-previews.mdx    | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/src/content/docs/aws/tutorials/ephemeral-application-previews.mdx b/src/content/docs/aws/tutorials/ephemeral-application-previews.mdx
index 76c0ab21..24396755 100644
--- a/src/content/docs/aws/tutorials/ephemeral-application-previews.mdx
+++ b/src/content/docs/aws/tutorials/ephemeral-application-previews.mdx
@@ -30,6 +30,11 @@ This allows you to run end-to-end tests, preview features, and collaborate withi
 
 This tutorial will show you how to use LocalStack's Ephemeral Instance feature to generate an Application Preview automatically for every new Pull Request (PR) using a GitHub Action workflow.
 
+:::note
+Ephemeral Instances are not supported by [`lstk`](/aws/developer-tools/running-localstack/lstk/).
+This tutorial instead uses the [legacy LocalStack CLI](/aws/developer-tools/running-localstack/localstack-cli/).
+:::
+
 ## Architecture diagram of the preview flow
 
 ![Ephemeral Previews Flow](/images/aws/empheral_previews_flow.png)

From 7329955d75682d6fa1231786295bd709396583e2 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Tue, 18 Aug 2026 10:14:54 +1200
Subject: [PATCH 14/18] Convert chaos-api tutorials.

---
 .../docs/aws/tutorials/route-53-failover.mdx   | 18 ++++++++++++------
 .../docs/aws/tutorials/simulating-outages.mdx  | 16 +++++++++++-----
 ...form-with-testcontainers-and-localstack.mdx |  6 ++++++
 3 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/src/content/docs/aws/tutorials/route-53-failover.mdx b/src/content/docs/aws/tutorials/route-53-failover.mdx
index 65775229..f0f1df69 100644
--- a/src/content/docs/aws/tutorials/route-53-failover.mdx
+++ b/src/content/docs/aws/tutorials/route-53-failover.mdx
@@ -32,7 +32,7 @@ In this example, there's an active-primary and passive-standby configuration.
 Route53 routes traffic to the primary region, which processes product-related requests through API Gateway and Lambda functions, with data stored in DynamoDB.
 If the primary region fails, Route53 redirects to the standby region, maintained in sync by a replication Lambda function.
 
-For this particular example, we'll be using a [sample application repository](https://github.com/localstack-samples/samples-chaos-engineering/tree/main/route53-failover).
+For this particular example, we'll be using a [sample application repository](https://github.com/localstack-samples/sample-chaos-serverless-multi-region-failover).
 Clone the repository, and follow the instructions below to get started.
 
 ### Prerequisites
@@ -40,7 +40,7 @@ Clone the repository, and follow the instructions below to get started.
 The general prerequisites for this guide are:
 
 - LocalStack for AWS with [LocalStack Auth Token](/aws/getting-started/auth-token)
-- [AWS CLI](/aws/connecting/aws-cli) with the [`awslocal` wrapper](/aws/connecting/aws-cli#localstack-aws-cli-awslocal)
+- [AWS CLI](/aws/connecting/aws-cli) with the [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws) command
 - [Docker](https://docs.docker.com/get-docker/) and [Docker Compose](https://docs.docker.com/compose/install/)
 - [Python-3](https://www.python.org/downloads/)
 - `dig`
@@ -53,6 +53,12 @@ LOCALSTACK_AUTH_TOKEN=<YOUR_LOCALSTACK_AUTH_TOKEN>
 docker compose up
 ```
 
+Given that you've started LocalStack via `docker-compose`, you'll need to configure the `lstk` CLI to contact your container:
+
+```bash
+export LSTK_ENDPOINT_URL=http://localhost.localstack.cloud:4566
+```
+
 ### Architecture
 
 The following diagram shows the architecture that this application builds and deploys:
@@ -80,14 +86,14 @@ Let's begin by setting up a hosted zone in Route53 named `hello-localstack.com`
 
 ```bash
 HOSTED_ZONE_NAME=hello-localstack.com
-HOSTED_ZONE_ID=$(awslocal route53 create-hosted-zone --name $HOSTED_ZONE_NAME --caller-reference foo | jq -r .HostedZone.Id)
+HOSTED_ZONE_ID=$(lstk aws route53 create-hosted-zone --name $HOSTED_ZONE_NAME --caller-reference foo | jq -r .HostedZone.Id)
 ```
 
 Then, define the health check ID for the API Gateway available in the `us-west-1` region:
 
 ```bash
 HEALTH_CHECK_ID=$(
-awslocal route53 create-health-check \
+lstk aws route53 create-health-check \
 --caller-reference foobar \
 --health-check-config '{
     "FullyQualifiedDomainName": "12345.execute-api.localhost.localstack.cloud",
@@ -106,7 +112,7 @@ To update DNS records in the specified Route53 hosted zone (`$HOSTED_ZONE_ID`),
 Set a TTL (Time to Live) of 60 seconds for these records.
 
 ```bash
-awslocal route53 change-resource-record-sets \
+lstk aws route53 change-resource-record-sets \
 --hosted-zone $HOSTED_ZONE_ID \
 --change-batch '{
     "Changes": [
@@ -142,7 +148,7 @@ The first record points to `12345.$HOSTED_ZONE_NAME` and is linked with the earl
 The second record points to `67890.$HOSTED_ZONE_NAME` and is set as the secondary failover target.
 
 ```bash
-awslocal route53 change-resource-record-sets \
+lstk aws route53 change-resource-record-sets \
 --hosted-zone-id $HOSTED_ZONE_ID \
 --change-batch '{
     "Changes": [
diff --git a/src/content/docs/aws/tutorials/simulating-outages.mdx b/src/content/docs/aws/tutorials/simulating-outages.mdx
index bf2274ec..bd809c89 100644
--- a/src/content/docs/aws/tutorials/simulating-outages.mdx
+++ b/src/content/docs/aws/tutorials/simulating-outages.mdx
@@ -25,11 +25,11 @@ Chaos API offers a means to deliberately introduce failures and observe their im
 In this tutorial we study the effects of outages on a sample AWS application.
 We use the Chaos API to simulate the outage and design a mitigation to make the application resilient against database outages.
 
-This tutorial is designed for users new to the Chaos API and assumes basic knowledge of the AWS CLI and our [`awslocal`](https://github.com/localstack/awscli-local) wrapper script.
+This tutorial is designed for users new to the Chaos API and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws) command.
 In this example, we will use the Chaos API to create controlled outages in a DynamoDB database.
 The aim is to test the software's behavior and error handling capabilities.
 
-For this particular example, we'll be using a [sample application repository](https://github.com/localstack-samples/samples-chaos-engineering/tree/master/chaos-api).
+For this particular example, we'll be using a [sample application repository](https://github.com/localstack-samples/sample-chaos-api-serverless).
 Clone the repository, and follow the instructions below to get started.
 
 ### Prerequisites
@@ -37,7 +37,7 @@ Clone the repository, and follow the instructions below to get started.
 The general prerequisites for this guide are:
 
 - LocalStack for AWS with [LocalStack Auth Token](/aws/getting-started/auth-token)
-- [AWS CLI](/aws/connecting/aws-cli) with the [`awslocal` wrapper](/aws/connecting/aws-cli#localstack-aws-cli-awslocal)
+- [AWS CLI](/aws/connecting/aws-cli) with the [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws) command
 - [Docker](https://docs.docker.com/get-docker/) and [Docker Compose](https://docs.docker.com/compose/install/)
 
 Start LocalStack by using the `docker-compose.yml` file from the repository.
@@ -49,6 +49,12 @@ LOCALSTACK_AUTH_TOKEN=<YOUR_LOCALSTACK_AUTH_TOKEN>
 docker compose up
 ```
 
+Given that you've started LocalStack via `docker-compose`, you'll need to configure the `lstk` CLI to contact your container:
+
+```bash
+export LSTK_ENDPOINT_URL=http://localhost.localstack.cloud:4566
+```
+
 ### Architecture
 
 The following diagram shows the architecture that this application builds and deploys:
@@ -80,7 +86,7 @@ Product added/updated successfully.
 After ending the outage, confirm that previously failed items are stored successfully:
 
 ```bash
-awslocal dynamodb scan --table-name Products
+lstk aws dynamodb scan --table-name Products
 ```
 
 Expected output:
@@ -184,7 +190,7 @@ With the outage now ended, the Product that initially failed to reach the databa
 This can be confirmed by scanning the database.
 
 ```bash
-awslocal dynamodb scan --table-name Products
+lstk aws dynamodb scan --table-name Products
 ```
 
 ```bash title="Output"
diff --git a/src/content/docs/aws/tutorials/using-terraform-with-testcontainers-and-localstack.mdx b/src/content/docs/aws/tutorials/using-terraform-with-testcontainers-and-localstack.mdx
index fd0ad9bf..80e9e72c 100644
--- a/src/content/docs/aws/tutorials/using-terraform-with-testcontainers-and-localstack.mdx
+++ b/src/content/docs/aws/tutorials/using-terraform-with-testcontainers-and-localstack.mdx
@@ -174,6 +174,12 @@ Volumes:
 
 After running `docker compose up`, we should keep an eye on the container logs until the `Ready.` message appears.
 
+Given that you've started LocalStack via `docker-compose`, you'll need to configure the `lstk` CLI to contact your container:
+
+```bash
+export LSTK_ENDPOINT_URL=http://localhost.localstack.cloud:4566
+```
+
 Now we can test the functionality of our stack by running the following commands:
 
 ```bash

From 709c763e84fab07c0bb94e9a282b8350ac4e3441 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Tue, 18 Aug 2026 10:29:02 +1200
Subject: [PATCH 15/18] Convert cloud-pods-collaborative

---
 .../cloud-pods-collaborative-debugging.mdx    | 59 ++++++++-----------
 1 file changed, 25 insertions(+), 34 deletions(-)

diff --git a/src/content/docs/aws/tutorials/cloud-pods-collaborative-debugging.mdx b/src/content/docs/aws/tutorials/cloud-pods-collaborative-debugging.mdx
index 2235f871..c5c64a98 100644
--- a/src/content/docs/aws/tutorials/cloud-pods-collaborative-debugging.mdx
+++ b/src/content/docs/aws/tutorials/cloud-pods-collaborative-debugging.mdx
@@ -31,9 +31,9 @@ The full sample application can be found [on GitHub](https://github.com/localsta
 
 ### **Prerequisites**
 
-- [LocalStack CLI](/aws/getting-started/installation#localstack-cli) (preferably using `pip`)
+- [`lstk`](/aws/getting-started/installation#lstk)
 - [Docker](https://docs.docker.com/engine/install/)
-- [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) or [OpenTofu](https://opentofu.org/docs/intro/install/) and [terraform-local](/aws/connecting/infrastructure-as-code/terraform#install-the-tflocal-wrapper-script)
+- [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) or [OpenTofu](https://opentofu.org/docs/intro/install/) and [`lstk terraform`](/aws/connecting/infrastructure-as-code/terraform#lstk-terraform)
 - Optional for Lambda build & editing: [Maven 3.9.4](https://maven.apache.org/install.html) & [Java 21](https://www.java.com/en/download/help/download_options.html)
 
 - Basic knowledge of AWS services (API Gateway, Lambda, DynamoDB, IAM)
@@ -72,6 +72,12 @@ export LOCALSTACK_AUTH_TOKEN=<your-auth-token>
 docker compose up
 ```
 
+Given that you've started LocalStack via `docker-compose`, you'll need to configure the `lstk` CLI to contact your container:
+
+```bash
+export LSTK_ENDPOINT_URL=http://localhost.localstack.cloud:4566
+```
+
 ### The Terraform Configuration File
 
 The entire Terraform configuration file for setting up the application stack is available in the same repository at
@@ -81,12 +87,12 @@ navigate to the project's root folder and use the following commands:
 
 ```bash
 cd terraform
-tflocal init
-tflocal plan
-tflocal apply --auto-approve
+lstk terraform init
+lstk terraform plan
+lstk terraform apply --auto-approve
 ```
 
-`tflocal` is a small wrapper script to run Terraform against LocalStack.
+`lstk terraform` runs Terraform against LocalStack, using LocalStack endpoints as AWS provider overrides.
 The endpoints for all services are configured to point to the
 LocalStack API, which allows you to deploy your unmodified Terraform scripts against LocalStack.
 
@@ -132,7 +138,7 @@ The Terraform configuration file outputs the REST API ID of the API Gateway.
 We can capture that value and use it further to invoke the **`add-product`** Lambda:
 
 ```bash
-export rest_api_id=$(cd terraform; tflocal output --raw rest_api_id)
+export rest_api_id=$(cd terraform; lstk terraform output --raw rest_api_id)
 ```
 
 The endpoint for the API Gateway is constructed similarly to the one on AWS:
@@ -186,10 +192,10 @@ The Lambda code and the configurations look fine to him.
 
 ### Creating a Cloud Pod
 
-To share this exact environment and issue with Alice, a more experienced colleague, Bob only needs to run a simple `localstack pod` command:
+To share this exact environment and issue with Alice, a more experienced colleague, Bob only needs to run a simple `lstk snapshot save` command:
 
 ```bash
-localstack pod save cloud-pod-product-app
+lstk snapshot save pod:cloud-pod-product-app
 ```
 
 ```bash title="Output"
@@ -201,31 +207,16 @@ Services: sts,iam,apigateway,dynamodb,lambda,s3,cloudwatch,logs
 
 LocalStack provides a remote storage backend that can be used to store the state of your application and share it with your team members.
 
-The Cloud Pods CLI is included in the LocalStack CLI installation, so there's no need for additional plugins to begin using it.
+Cloud Pods are managed through the `snapshot` command, included in the `lstk` CLI installation, so there's no need for additional plugins to begin using it.
 The `LOCALSTACK_AUTH_TOKEN` needs to be set as an environment variable.
 
-Additionally, there are other commands for managing Cloud Pods included in the CLI:
-
-```bash
-localstack pod --help
-```
-
-```bash title="Output"
-Usage: localstack pod [OPTIONS] COMMAND [ARGS]...
-
-  Manage the state of your instance via Cloud Pods.
-
-Options:
-  -h, --help  Show this message and exit.
+Additionally, there are other `snapshot` subcommands for managing Cloud Pods:
 
-Commands:
-  delete    Delete a Cloud Pod
-  list      List all available Cloud Pods
-  load      Load the state of a Cloud Pod into the application runtime
-  remote    Manage Cloud Pod remotes
-  save      Create a new Cloud Pod
-  versions  List all available versions for a Cloud Pod
-```
+- `lstk snapshot save` (alias `lstk save`) — create a new Cloud Pod
+- `lstk snapshot load` (alias `lstk load`) — load the state of a Cloud Pod into the application runtime
+- `lstk snapshot list` — list all available Cloud Pods
+- `lstk snapshot remove` — delete a Cloud Pod
+- `lstk snapshot show` — show metadata for a Cloud Pod
 
 ### Pulling and Loading the Cloud Pod
 
@@ -237,7 +228,7 @@ Now, in a fresh LocalStack instance, Alice can immediately load the Cloud Pod, b
 same organization:
 
 ```bash
-localstack pod load  cloud-pod-product-app
+lstk snapshot load pod:cloud-pod-product-app
 ```
 
 ```bash title="Output"
@@ -329,10 +320,10 @@ start to finish.
 
 ### Other Remote Options
 
-For organizations with specific data regulations, LocalStack offers multiple remote storage options for Cloud Pods,
+For organizations with specific data regulations, LocalStack offers an Amazon S3 storage option,
 allowing full control with on-premises storage if needed.
 That way, Bob, Alice and Carol could collaborate using an S3 bucket for remote storage.
-The Cloud Pods command-line interface enables users to manage these remotes with ease, by following the instructions in the
+The `lstk` command-line interface enables users to manage this storage with ease, by following the instructions in the
 [documentation](/aws/developer-tools/snapshots/saving-snapshots-to-s3).
 
 ## Conclusion

From c59924ebac1bfd7ff91afa64cda8c9264e5d3138 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Wed, 19 Aug 2026 09:43:21 +1200
Subject: [PATCH 16/18] Convert reproducible-machine-learning

---
 ...producible-machine-learning-cloud-pods.mdx | 131 +++++++++---------
 1 file changed, 68 insertions(+), 63 deletions(-)

diff --git a/src/content/docs/aws/tutorials/reproducible-machine-learning-cloud-pods.mdx b/src/content/docs/aws/tutorials/reproducible-machine-learning-cloud-pods.mdx
index ccdd8f97..4476dc04 100644
--- a/src/content/docs/aws/tutorials/reproducible-machine-learning-cloud-pods.mdx
+++ b/src/content/docs/aws/tutorials/reproducible-machine-learning-cloud-pods.mdx
@@ -17,11 +17,10 @@ leadimage: "reproducible-machine-learning-cloud-pods-featured-image.png"
 
 [LocalStack Cloud Pods](/aws/developer-tools/snapshots/cloud-pods) enable you to create persistent state snapshots of your LocalStack instance, which can then be versioned, shared, and restored.
 It allows next-generation state management and team collaboration for your local cloud development environment, which you can utilize to create persistent shareable cloud sandboxes.
-Cloud Pods works directly with the [LocalStack CLI](/aws/connecting/aws-cli#localstack-aws-cli-awslocal) to save, merge, and restore snapshots of your LocalStack state.
+Cloud Pods works directly with the [`lstk`](/aws/developer-tools/running-localstack/lstk/) CLI to save, merge, and restore snapshots of your LocalStack state.
 You can always tear down your LocalStack instance and restore it from a snapshot at any point in time.
 
-Cloud Pods is supported in [LocalStack Team](https://app.localstack.cloud/).
-With LocalStack Team, you can utilize the Cloud Pods CLI that allows you to inspect your Cloud Pods, version them using tags, and push them to the LocalStack platform for storage and collaboration.
+The `lstk snapshot` commands allow you to inspect your Cloud Pods, version them, and push them to the LocalStack platform for storage and collaboration.
 
 In this tutorial, we will use [LocalStack for AWS](/aws/getting-started/auth-token) to train a simple machine-learning model that recognizes handwritten digits on an image.
 We will rely on Cloud Pods to create a reproducible sample by using:
@@ -40,12 +39,12 @@ We will then create a Cloud Pod to save the state of our LocalStack instance and
 For this tutorial, you will need the following:
 
 - [LocalStack for AWS](https://localstack.cloud/pricing/)
-- [awslocal](/aws/connecting/aws-cli#localstack-aws-cli-awslocal)
+- [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws)
 - [Optical recognition of handwritten digits dataset](https://github.com/localstack-samples/localstack-pro-samples/raw/refs/heads/master/reproducible-ml/digits.csv.gz) ([Source](https://archive.ics.uci.edu/ml/datasets/Optical+Recognition+of+Handwritten+Digits))
 
 If you don't have a subscription to LocalStack for AWS, you can request a trial license upon sign-up.
-For this tutorial to work, you must have the LocalStack CLI installed, which must be version 1.3 or higher.
-The Cloud Pods CLI is shipped with the LocalStack CLI, so you don't need to install it separately.
+For this tutorial to work, you must have [`lstk`](/aws/getting-started/installation#lstk) installed.
+Cloud Pods (via the `lstk snapshot` command) are built into the `lstk` CLI, so you don't need to install it separately.
 
 ## Training the machine learning model
 
@@ -189,28 +188,29 @@ Before creating our Lambda functions, let us start LocalStack to use emulated S3
 Let's start LocalStack:
 
 ```bash
-DEBUG=1 LOCALSTACK_AUTH_TOKEN=<your-auth-token> localstack start -d
+LOCALSTACK_DEBUG=1 lstk start
 ```
 
-We have specified `DEBUG=1` to get the printed LocalStack logs from our Lambda invocation in the console.
+We have specified `LOCALSTACK_DEBUG=1` so that the logs from our Lambda invocations are recorded by LocalStack.
+Since `lstk start` runs the emulator in the background, we will read those logs with `lstk logs`.
 We can now create an S3 bucket to upload our Lambda functions and the dataset:
 
 ```bash
 zip lambda.zip train.py
 zip infer.zip infer.py
-awslocal s3 mb s3://reproducible-ml
-awslocal s3 cp lambda.zip s3://reproducible-ml/lambda.zip
-awslocal s3 cp infer.zip s3://reproducible-ml/infer.zip
-awslocal s3 cp digits.csv.gz s3://reproducible-ml/digits.csv.gz
+lstk aws s3 mb s3://reproducible-ml
+lstk aws s3 cp lambda.zip s3://reproducible-ml/lambda.zip
+lstk aws s3 cp infer.zip s3://reproducible-ml/infer.zip
+lstk aws s3 cp digits.csv.gz s3://reproducible-ml/digits.csv.gz
 ```
 
 In the above commands, we first create two zip files for our Lambda functions: lambda.zip and infer.zip.
 These zip files contain the code for training the machine learning model and do predictions with it, respectively.
 Next, we create an S3 bucket called `reproducible-ml` and upload the zip files and the dataset to it.
-Finally, we use the `awslocal` CLI to create the two Lambda functions
+Finally, we use the `lstk aws` CLI to create the two Lambda functions
 
 ```bash
-awslocal lambda create-function --function-name ml-train \
+lstk aws lambda create-function --function-name ml-train \
   --runtime python3.8 \
   --role arn:aws:iam::000000000000:role/lambda-role \
   --handler train.handler \
@@ -220,7 +220,7 @@ awslocal lambda create-function --function-name ml-train \
 ```
 
 ```bash
-awslocal lambda create-function --function-name ml-predict \
+lstk aws lambda create-function --function-name ml-predict \
   --runtime python3.8 \
   --role arn:aws:iam::000000000000:role/lambda-role \
   --handler infer.handler \
@@ -233,111 +233,116 @@ For each function, we provide the function name, runtime (`python3.8`), handler
 We have also specified the `python-3-8-scikit-learn-0-23-1` layer to be used by the Lambda function.
 This layer includes the scikit-learn library and its dependencies.
 
-We can now invoke the first Lambda function using the `awslocal` CLI:
+We can now invoke the first Lambda function using the `lstk aws` CLI:
 
 ```bash
-awslocal lambda invoke --function-name ml-train /tmp/test.tmp
+lstk aws lambda invoke --function-name ml-train /tmp/test.tmp
 ```
 
 The first Lambda function will train the model and upload it to the S3 bucket.
 Finally, we can invoke the second Lambda function to do predictions with the model.
 
 ```bash
-awslocal lambda invoke --function-name ml-predict /tmp/test.tmp
+lstk aws lambda invoke --function-name ml-predict /tmp/test.tmp
 ```
 
-The logs of the Lambda invocation should be visible in the LocalStack container output (with `DEBUG=1` enabled):
+Each `invoke` call writes the function's return value to `/tmp/test.tmp` and prints the invocation status:
+
+```bash title="Output"
+{
+    "StatusCode": 200,
+    "ExecutedVersion": "$LATEST"
+}
+```
+
+The prediction output itself is logged by LocalStack (with `LOCALSTACK_DEBUG=1` enabled).
+Retrieve it with the `logs` command:
 
 ```bash
-null
->START RequestId: 65dc894d-25e0-168e-dea1-a3e8bfdb563b Version: $LATEST
-> --> prediction result: [8 8 4 9 0 8 9 8 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 9 6 7 8 9
-...
+lstk logs
+```
+
+```bash title="Output"
+2026-08-18T20:06:25.174 DEBUG --- [et.reactor-2] l.p.c.s.l.i.version_manage : [ml-predict-f5e813df-cc00-41ef-bb88-5075f4d05ff7] START RequestId: f5e813df-cc00-41ef-bb88-5075f4d05ff7 Version: $LATEST
+2026-08-18T20:06:25.174 DEBUG --- [et.reactor-2] l.p.c.s.l.i.version_manage : [ml-predict-f5e813df-cc00-41ef-bb88-5075f4d05ff7] --> prediction result: [8 8 4 9 0 8 9 8 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 9 6 7 8 9
 ...
->  9 5 4 8 8 4 9 0 8 9 8]
-> END RequestId: 6...
+2026-08-18T20:06:25.177 DEBUG --- [et.reactor-2] l.p.c.s.l.i.version_manage : [ml-predict-f5e813df-cc00-41ef-bb88-5075f4d05ff7]  9 5 4 8 8 4 9 0 8 9 8]
+2026-08-18T20:06:25.178 DEBUG --- [et.reactor-2] l.p.c.s.l.i.version_manage : [ml-predict-f5e813df-cc00-41ef-bb88-5075f4d05ff7] END RequestId: f5e813df-cc00-41ef-bb88-5075f4d05ff7
 ```
 
+You can also stream the logs with `lstk logs --follow`.
+
 ## Creating a Cloud Pod
 
 After deploying the Lambda functions, we can create a Cloud Pod to share our local infrastructure and instance state with other LocalStack users in the organization.
 To save the current state of our LocalStack instance, we can use the `save` command:
 
 ```bash
-localstack pod save reproducible-ml
+lstk snapshot save pod:reproducible-ml
 ```
 
 ```bash title="Output"
-Cloud Pod reproducible-ml successfully created
+Saving snapshot to pod "reproducible-ml"......
+✔︎ Snapshot saved to pod:reproducible-ml
+• Version: 1
+• Services: lambda, cloudwatch, logs, s3, sts
+• Size: 40.8 MB
 ```
 
 :::note
-You can also export a Cloud Pod locally by specifying a file URI as an argument.
+You can also save a snapshot locally by specifying a plain path as an argument, instead of a `pod:` destination.
 To export on a local path, run the following command:
 
 ```bash
-localstack pod save file://<path_on_disk>/<pod_name>
+lstk snapshot save <path_on_disk>/<snapshot_name>
 ```
 
-The output of the above command will be a `<pod_name>` zip file in the specified directory.
+The output of the above command will be a `<snapshot_name>.snapshot` file in the specified directory.
 We can restore it at any time with the `load` command.
 :::
 
 To list available the Cloud Pods you can use the `list` command:
 
 ```bash
-localstack pod list
+lstk snapshot list
 ```
 
 ```bash title="Output"
-┏━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━┓
-┃ local/remote ┃ Name            ┃
-┡━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━┩
-│ local+remote │ reproducible-ml │
-└──────────────┴─────────────────┘
+Fetching snapshots...
+~ 1 snapshots
+
+  NAME             VERSION  LAST CHANGED
+  reproducible-ml  1        2026-08-18 20:08 UTC
 ```
 
-You can also inspect the contents of a Cloud Pod using the `inspect` command:
+You can also inspect the contents of a Cloud Pod using the `show` command:
 
 ```bash
-localstack pod inspect reproducible-ml
+lstk snapshot show pod:reproducible-ml
 ```
 
 While you save a Cloud Pod, it is automatically published on the LocalStack platform and can be shared with other users in your organization.
 While saving an already existing Cloud Pod, we would create a new version, which is eventually uploaded to the LocalStack platform.
 
-:::note
-You can optionally set the visibility of a Cloud Pod to `private` or `public` using the `--visibility` flag.
-By default, the visibility of a Cloud Pod is set to `private`.
-To set a Cloud Pod to `public`, you can use the following command:
-
-```bash
-localstack pod save --name <pod_name> --visibility public
-```
-
-The above command does not create a new version and requires a version already registered with the platform.
-:::
 
-You can also attach an optional message and a list of services to a Cloud Pod using the `--message` and `--services` flags.
 You can check all the Cloud Pods in your organization over the [LocalStack Web Application](https://app.localstack.cloud/pods).
 Now that we have created a Cloud Pod, we can ask one of our team members to start LocalStack and load the Cloud Pod using the `load` command.
 
 ```bash
-localstack pod load reproducible-ml
+lstk snapshot load pod:reproducible-ml
 ```
 
 The `load` command will retrieve the content of our Cloud Pod named `reproducible-ml` from the LocalStack platform and inject it into our running LocalStack instance.
 Upon successfully loading the Cloud Pod, the Lambda function can be invoked again, and the log output should be the same as before.
 
-LocalStack Cloud Pods also feature different merge strategies to merge the state of a Cloud Pod with the current LocalStack instance.
+LocalStack Cloud Pods also feature different [merge strategies](/aws/developer-tools/snapshots/merging-snapshots/) to merge the state of a Cloud Pod with the current LocalStack instance.
 You can use the `--merge` flag to specify the merge strategy.
 The available merge strategies are:
 
-- **Load with overwrite**: This is the default merge strategy.
-  It will load the state of the Cloud Pod into the current LocalStack instance and overwrite the existing state.
-- **Load with basic merge**: This merge strategy will load the state of the Cloud Pod into the current LocalStack instance and merge the existing state with the state of the Cloud Pod.
-- **Load with deep merge**: This merge strategy will load the state of the Cloud Pod into the current LocalStack instance and merge the existing state with the state of the Cloud Pod.
-  It will also merge the existing state with the state of the Cloud Pod recursively.
+- **`account-region-merge`**: This is the default merge strategy.
+  The state of the Cloud Pod wins wherever it overlaps with the running state on a (service, account, region) combination.
+- **`overwrite`**: This merge strategy wipes the running state, then loads the state of the Cloud Pod into the current LocalStack instance.
+- **`service-merge`**: This merge strategy combines non-overlapping resources, and the state of the Cloud Pod wins on a per-resource basis.
 
 ![State Merge mechanisms with LocalStack Cloud Pods](/images/aws/cloud-pods-state-merge-mechanisms.png)
 
@@ -347,19 +352,19 @@ After deploying and invoking the Lambdas, first verify the end-to-end ML workflo
 
 ### Expected Outputs from Training
 
-Invoke `ml-train` with: `awslocal lambda invoke --function-name ml-train /tmp/test.tmp`
+Invoke `ml-train` with: `lstk aws lambda invoke --function-name ml-train /tmp/test.tmp`
 
 - Logs show dataset load (1797 samples), training on 50% split, and S3 uploads for `model.joblib` and `test-set.npy`.
 - No explicit accuracy during training (focus is on savings), but the SVM classifier fits successfully.
 
 ### Expected Outputs from Inference (ml-predict Invocation)
 
-Invoke `ml-predict` with: `awslocal lambda invoke --function-name ml-predict /tmp/test.tmp`
+Invoke `ml-predict` with: `lstk aws lambda invoke --function-name ml-predict /tmp/test.tmp`
 
 - Downloads model and test set from S3.
 - Runs predictions on the test set (898 samples).
 - **Sample prediction result** (first 20): `[8 8 4 9 0 8 9 8 1 2 3 4 5 6 7 8 9 0 1 2]`
-- **Expected accuracy**: ~96.9% (calculated as `accuracy_score(y_test, predicted)`—e.g., 870/898 correct). Full logs in LocalStack output (with `DEBUG=1`):
+- **Expected accuracy**: ~96.9% (calculated as `accuracy_score(y_test, predicted)`—e.g., 870/898 correct). Full logs in LocalStack output (with `LOCALSTACK_DEBUG=1`):
 --> prediction result: [8 8 4 9 0 8 9 8 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 9 6 7 8 9 ... 9 5 4 8 8 4 9 0 8 9 8]
 
 
@@ -377,11 +382,11 @@ Expected Model accuracy: 0.9689
 
 ### Validation After Pod Restore
 
-- Save Pod: `localstack pod save reproducible-ml`
-- (In a new instance) Load: `localstack pod load reproducible-ml`
+- Save Pod: `lstk snapshot save pod:reproducible-ml`
+- (In a new instance) Load: `lstk snapshot load pod:reproducible-ml`
 - Re-invoke `ml-predict`: Outputs should match exactly, proving state persistence (S3 objects, Lambdas intact).
 
-If a mismatch occurs, check the Pod's merge strategy `(default: overwrite)` or logs for S3/Lambda errors.
+If a mismatch occurs, check the Pod's merge strategy `(default: account-region-merge)` or logs for S3/Lambda errors.
 
 ## Conclusion
 

From cf88f15a7dd4a93a8dc2b39edbd38d193600d2fa Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Wed, 19 Aug 2026 09:58:29 +1200
Subject: [PATCH 17/18] Convert iam-policy-stream

---
 .../docs/aws/tutorials/iam-policy-stream.mdx  | 68 +++++++++++--------
 1 file changed, 40 insertions(+), 28 deletions(-)

diff --git a/src/content/docs/aws/tutorials/iam-policy-stream.mdx b/src/content/docs/aws/tutorials/iam-policy-stream.mdx
index 55e155af..5305b8e8 100644
--- a/src/content/docs/aws/tutorials/iam-policy-stream.mdx
+++ b/src/content/docs/aws/tutorials/iam-policy-stream.mdx
@@ -19,7 +19,7 @@ When you're developing cloud and serverless applications, you need to grant acce
 To handle this, you create IAM roles and assign permissions through policies.
 However, configuring these policies can be challenging, especially if you want to ensure minimal access of all principals to your resources.
 
-[LocalStack IAM Policy Stream](https://app.localstack.cloud/policy-stream) automates the generation of IAM policies for your AWS API requests on your local machine.
+[LocalStack IAM Policy Stream](https://app.localstack.cloud/inst/default/policy-stream) automates the generation of IAM policies for your AWS API requests on your local machine.
 This stream helps you identify the necessary permissions for your cloud application and allows you to detect logical errors, such as unexpected actions in your policies.
 
 This tutorial will guide you through setting up IAM Policy Stream for a locally running AWS application.
@@ -41,10 +41,10 @@ Additionally, it serves as a useful learning tool, helping users understand the
 
 ## Prerequisites
 
-- [LocalStack CLI](/aws/getting-started/installation)  with  [`LOCALSTACK_AUTH_TOKEN`](/aws/getting-started/auth-token)
+- [`lstk`](/aws/getting-started/installation#lstk)  with  [`LOCALSTACK_AUTH_TOKEN`](/aws/getting-started/auth-token)
 - [Docker](https://docs.docker.com/get-docker/)
-- [Terraform](https://developer.hashicorp.com/terraform/install) & [`tflocal` wrapper](https://github.com/localstack/terraform-local)
-- [AWS](https://docs.aws.amazon.com/cli/v1/userguide/cli-chap-install.html)  CLI with  [`awslocal` wrapper](https://github.com/localstack/awscli-local)
+- [Terraform](https://developer.hashicorp.com/terraform/install) & [`lstk terraform`](/aws/connecting/infrastructure-as-code/terraform#lstk-terraform)
+- [AWS](https://docs.aws.amazon.com/cli/v1/userguide/cli-chap-install.html)  CLI with  [`lstk aws`](/aws/connecting/aws-cli#localstack-aws-cli-lstk-aws)
 - [LocalStack account](https://www.localstack.cloud/pricing)
 - [`jq`](https://jqlang.github.io/jq/download/)
 
@@ -74,13 +74,13 @@ With LocalStack's IAM enforcement enabled, you can thoroughly test your policy a
 Launch the LocalStack container on your local machine using the specified command:
 
 ```bash
-DEBUG=1 IAM_SOFT_MODE=1 localstack start
+LOCALSTACK_DEBUG=1 LOCALSTACK_IAM_SOFT_MODE=1 lstk start
 ```
 
 In the above command:
 
-- `DEBUG=1` turns on detailed logging to check API calls and IAM violations.
-- `IAM_SOFT_MODE=1` lets you test IAM enforcement by logging violations without stopping the API calls.
+- `LOCALSTACK_DEBUG=1` turns on detailed logging to check API calls and IAM violations.
+- `LOCALSTACK_IAM_SOFT_MODE=1` lets you test IAM enforcement by logging violations without stopping the API calls.
 
 ### Create the Terraform configuration
 
@@ -116,12 +116,12 @@ resource "aws_s3_bucket_notification" "bucket_notification" {
 
 ### Deploy the Terraform configuration
 
-You can use `tflocal` to deploy your Terraform configuration within the LocalStack environment.
+You can use `lstk terraform` to deploy your Terraform configuration within the LocalStack environment.
 Run the following commands to initialize and apply the Terraform configuration:
 
 ```bash
-tflocal init
-tflocal apply
+lstk terraform init
+lstk terraform apply
 ```
 
 You will be prompted to confirm the changes.
@@ -145,7 +145,7 @@ Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
 
 ### Start the IAM Policy Stream
 
-Access the [LocalStack Web Application](https://app.localstack.cloud/) and go to the [IAM Policy Stream dashboard](https://app.localstack.cloud/policy-stream).
+Access the [LocalStack Web Application](https://app.localstack.cloud/) and go to the [IAM Policy Stream dashboard](https://app.localstack.cloud/inst/default/policy-stream).
 This feature enables you to directly examine the generated policies, displaying the precise permissions required for each API call.
 
 ![IAM Policy Stream dashboard](/images/aws/iam-policy-stream-dashboard.png)
@@ -159,11 +159,11 @@ Create a new file named `some-log-file.log` and upload it to the S3 bucket using
 
 ```bash
 echo "Hello, LocalStack" > some-log-file.log
-awslocal s3 cp some-log-file.log s3://s3-event-notification-bucket/
+lstk aws s3 cp some-log-file.log s3://s3-event-notification-bucket/
 ```
 
 Uploading a file will activate an event notification, sending a message to the SQS queue.
-However, since the SQS queue lacks the necessary permissions, an IAM violation will appear in the [IAM Policy Stream dashboard](https://app.localstack.cloud/policy-stream).
+However, since the SQS queue lacks the necessary permissions, an IAM violation will appear in the [IAM Policy Stream dashboard](https://app.localstack.cloud/inst/default/policy-stream).
 
 ![IAM Policy Stream showcasing an IAM violation](/images/aws/iam-policy-stream-violation.png)
 
@@ -221,14 +221,14 @@ POLICY
 Now, re-apply the Terraform configuration to update the SQS queue with the new policy:
 
 ```bash
-tflocal apply
+lstk terraform apply
 ```
 
 Next, trigger the event notification again by uploading a file to the S3 bucket.
 You can confirm that the S3 bucket is correctly set up for event notifications through the SQS queue by checking if the message is received in the SQS queue:
 
 ```bash
-awslocal sqs receive-message \
+lstk aws sqs receive-message \
     --queue-url http://sqs.us-east-1.localhost.localstack.cloud:4566/000000000000/s3-event-notification-queue
 ```
 
@@ -273,13 +273,13 @@ This section demonstrates how to test your IAM policies and verify both deny and
 
 ### Testing Scenario 1: Deny (Without IAM Policy)
 
-When you first upload a file to the S3 bucket without the proper SQS queue policy in place, the S3 service will be denied permission to send messages to the SQS queue.
+When you first upload a file to the S3 bucket without the proper SQS queue policy in place, S3 has no permission to send messages to the SQS queue, and the violation is reported.
 
 **Upload a test file:**
 
 ```bash
 echo "Test file content" > test-file.log
-awslocal s3 cp test-file.log s3://s3-event-notification-bucket/
+lstk aws s3 cp test-file.log s3://s3-event-notification-bucket/
 ```
 
 **Expected output - IAM Violation in LocalStack logs:**
@@ -305,19 +305,28 @@ The dashboard clearly shows:
 **Attempting to receive messages from the queue:**
 
 ```bash
-awslocal sqs receive-message \
+lstk aws sqs receive-message \
     --queue-url http://sqs.us-east-1.localhost.localstack.cloud:4566/000000000000/s3-event-notification-queue
 ```
 
-**Expected output - No messages (because S3 was denied):**
+**Expected output - the message is still delivered, because soft mode does not block the call:**
 
 ```json
 {
-    "Messages": []
+    "Messages": [
+        {
+            "MessageId": "5da627c5-5b4b-4202-a499-510222727e43",
+            "ReceiptHandle": "NWMyZDA1MDEtM2NlYi00MzBjLWIyNjQtYjM2ZjNmYmQxZTAyIGFybjphd3M6c3FzOnVzLWVhc3QtMTowMDAwMDAwMDAwMDA6czMtZXZlbnQtbm90aWZpY2F0aW9uLXF1ZXVlIDVkYTYyN2M1LTViNGItNDIwMi1hNDk5LTUxMDIyMjcyN2U0MyAxNzg2NjY1NzQ3LjQ3ODI1MTI=",
+            "MD5OfBody": "dee5cf145a0678a0ac02e3b38aa302f7",
+            "Body": "{\"Records\": [{\"eventVersion\": \"2.1\", \"eventSource\": \"aws:s3\", \"awsRegion\": \"us-east-1\", \"eventName\": \"ObjectCreated:Put\", \"s3\": {\"bucket\": {\"name\": \"s3-event-notification-bucket\"}, \"object\": {\"key\": \"test-file.log\", \"size\": 18}}}]}"
+        }
+    ]
 }
 ```
 
-Or you may receive no output at all, indicating an empty queue.
+:::note
+In a production environment, where the same policy gap would be enforced by real AWS IAM, this `SendMessage` call would fail and the message would never arrive.
+:::
 
 ### Testing Scenario 2: Allow (With IAM Policy)
 
@@ -353,7 +362,7 @@ After applying the IAM policy generated by the Policy Stream to your SQS queue,
 
 ```bash
 echo "Test file with policy" > test-file-2.log
-awslocal s3 cp test-file-2.log s3://s3-event-notification-bucket/
+lstk aws s3 cp test-file-2.log s3://s3-event-notification-bucket/
 ```
 
 **Expected output - Success (no IAM violation):**
@@ -362,13 +371,16 @@ awslocal s3 cp test-file-2.log s3://s3-event-notification-bucket/
 upload: ./test-file-2.log to s3://s3-event-notification-bucket/test-file-2.log
 ```
 
-**LocalStack logs showing successful permission:**
+**LocalStack logs:**
 
-```shell
-2024-07-09T05:35:22.123 DEBUG --- [et.reactor-2] l.s.i.p.handler            : Request for service 'sqs' by principal 's3.amazonaws.com' for operation 'SendMessage' allowed.
-2024-07-09T05:35:22.123 DEBUG --- [et.reactor-2] l.s.i.p.handler            : 1 permissions have been explicitly allowed: ["Action 'sqs:SendMessage' for 'arn:aws:sqs:us-east-1:000000000000:s3-event-notification-queue'"]
+An allowed request produces no output from the IAM policy handler — only denials are logged.
+
+```bash
+lstk logs | grep "i.p.handler"
 ```
 
+Only the entries from the earlier, un-permitted upload should remain.
+
 **IAM Policy Stream Dashboard showing no violations:**
 
 ![IAM Policy Stream showcasing no violations](/images/aws/iam-policy-stream-no-violations.png)
@@ -378,7 +390,7 @@ The dashboard shows all actions with green checkmarks, indicating successful exe
 **Receive the message from the queue:**
 
 ```bash
-awslocal sqs receive-message \
+lstk aws sqs receive-message \
     --queue-url http://sqs.us-east-1.localhost.localstack.cloud:4566/000000000000/s3-event-notification-queue
 ```
 
@@ -405,7 +417,7 @@ To ensure your IAM policies are correctly configured:
 
 - **No IAM violations** appear in the IAM Policy Stream dashboard
 - **Messages are successfully delivered** to the SQS queue
-- **LocalStack logs show "allowed"** for the `SendMessage` operation
+- **No new violation entries** are logged for the `SendMessage` operation after the policy is applied
 - **All API calls display green checkmarks** in the Policy Stream dashboard
 
 ## Conclusion

From 0901a2969035252ee39a43bc4ab8f30b7c71792a Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.smith@localstack.cloud>
Date: Wed, 19 Aug 2026 10:39:45 +1200
Subject: [PATCH 18/18] Last minute PR fixes.

---
 .../docs/aws/tutorials/aws-proxy-localstack-extension.mdx       | 2 +-
 .../aws/tutorials/reproducible-machine-learning-cloud-pods.mdx  | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/content/docs/aws/tutorials/aws-proxy-localstack-extension.mdx b/src/content/docs/aws/tutorials/aws-proxy-localstack-extension.mdx
index 792362ec..0eaa090f 100644
--- a/src/content/docs/aws/tutorials/aws-proxy-localstack-extension.mdx
+++ b/src/content/docs/aws/tutorials/aws-proxy-localstack-extension.mdx
@@ -7,7 +7,7 @@ services:
 platform:
 - Python
 deployment:
-- lstk aws
+- awscli
 pro: true
 leadimage: "aws-proxy-extension-tutorial-cover.png"
 ---
diff --git a/src/content/docs/aws/tutorials/reproducible-machine-learning-cloud-pods.mdx b/src/content/docs/aws/tutorials/reproducible-machine-learning-cloud-pods.mdx
index 4476dc04..f55147da 100644
--- a/src/content/docs/aws/tutorials/reproducible-machine-learning-cloud-pods.mdx
+++ b/src/content/docs/aws/tutorials/reproducible-machine-learning-cloud-pods.mdx
@@ -44,7 +44,6 @@ For this tutorial, you will need the following:
 
 If you don't have a subscription to LocalStack for AWS, you can request a trial license upon sign-up.
 For this tutorial to work, you must have [`lstk`](/aws/getting-started/installation#lstk) installed.
-Cloud Pods (via the `lstk snapshot` command) are built into the `lstk` CLI, so you don't need to install it separately.
 
 ## Training the machine learning model