diff --git a/astro.config.mjs b/astro.config.mjs index 942342b6..61c53f31 100644 --- a/astro.config.mjs +++ b/astro.config.mjs @@ -484,7 +484,45 @@ export default defineConfig({ }, { label: 'lstk CLI', - slug: 'aws/developer-tools/running-localstack/lstk', + collapsed: true, + items: [ + { + label: 'Overview', + slug: 'aws/developer-tools/running-localstack/lstk', + }, + { + label: 'Authentication', + slug: 'aws/developer-tools/running-localstack/lstk/authentication', + }, + { + label: 'Configuration', + slug: 'aws/developer-tools/running-localstack/lstk/configuration', + }, + { + label: 'Lifecycle Commands', + slug: 'aws/developer-tools/running-localstack/lstk/lifecycle-commands', + }, + { + label: 'AWS & IaC Commands', + slug: 'aws/developer-tools/running-localstack/lstk/aws-and-iac-commands', + }, + { + label: 'Snapshots', + slug: 'aws/developer-tools/running-localstack/lstk/snapshots', + }, + { + label: 'Automation & CI', + slug: 'aws/developer-tools/running-localstack/lstk/automation', + }, + { + label: 'Setup & Maintenance', + slug: 'aws/developer-tools/running-localstack/lstk/setup-and-maintenance', + }, + { + label: 'FAQ & Troubleshooting', + slug: 'aws/developer-tools/running-localstack/lstk/faq-and-troubleshooting', + }, + ], }, { label: 'LocalStack MCP Server', diff --git a/public/_redirects b/public/_redirects index e8cf09ff..f023e045 100644 --- a/public/_redirects +++ b/public/_redirects @@ -379,7 +379,7 @@ /user-guide/aws/stepfunctions/ /aws/services/stepfunctions/ 301 /references/coverage/coverage_elasticache/ /aws/services/elasticache/ 301 /applications/mnist-handwritten-digit-recognition-model-running-on-a-local-sagemaker-endpoint/ https://github.com/localstack-samples/sample-mnist-digit-recognition-sagemaker 301 -/user-guide/state-management/pods-cli/ /aws/developer-tools/running-localstack/lstk/#snapshot 301 +/user-guide/state-management/pods-cli/ /aws/developer-tools/running-localstack/lstk/snapshots/#snapshot 301 /user-guide/aws/dynamodbstreams/ /aws/services/dynamodbstreams/ 301 /references/api-key/ /aws/getting-started/auth-token/#how-do-i-activate-older-versions-of-localstack-before-v30/ 301 /references/coverage/coverage_eks/ /aws/services/eks/ 301 @@ -779,7 +779,7 @@ /user-guide/aws/stepfunctions /aws/services/stepfunctions/ 301 /references/coverage/coverage_elasticache /aws/services/elasticache/ 301 /applications/mnist-handwritten-digit-recognition-model-running-on-a-local-sagemaker-endpoint https://github.com/localstack-samples/sample-mnist-digit-recognition-sagemaker 301 -/user-guide/state-management/pods-cli /aws/developer-tools/running-localstack/lstk/#snapshot 301 +/user-guide/state-management/pods-cli /aws/developer-tools/running-localstack/lstk/snapshots/#snapshot 301 /user-guide/aws/dynamodbstreams /aws/services/dynamodbstreams/ 301 /references/api-key /aws/getting-started/auth-token/#how-do-i-activate-older-versions-of-localstack-before-v30/ 301 /references/coverage/coverage_eks /aws/services/eks/ 301 @@ -861,15 +861,15 @@ /aws/integrations/aws-native-tools /aws/connecting/ 301 /aws/integrations/infrastructure-as-code/ /aws/connecting/infrastructure-as-code/ 301 /aws/integrations/infrastructure-as-code /aws/connecting/infrastructure-as-code/ 301 -/aws/capabilities/state-management/cli-commands /aws/developer-tools/running-localstack/lstk/#snapshot 301 -/aws/capabilities/state-management/cli-commands/ /aws/developer-tools/running-localstack/lstk/#snapshot 301 +/aws/capabilities/state-management/cli-commands /aws/developer-tools/running-localstack/lstk/snapshots/#snapshot 301 +/aws/capabilities/state-management/cli-commands/ /aws/developer-tools/running-localstack/lstk/snapshots/#snapshot 301 /aws/capabilities/state-management/export-import-state /aws/developer-tools/snapshots/saving-snapshots-locally/ 301 /aws/capabilities/state-management/export-import-state/ /aws/developer-tools/snapshots/saving-snapshots-locally/ 301 /aws/capabilities/state-management/ /aws/developer-tools/snapshots/ 301 /aws/developer-tools/snapshots/export-import-state /aws/developer-tools/snapshots/saving-snapshots-locally/ 301 /aws/developer-tools/snapshots/export-import-state/ /aws/developer-tools/snapshots/saving-snapshots-locally/ 301 -/aws/developer-tools/snapshots/cli-commands /aws/developer-tools/running-localstack/lstk/#snapshot 301 -/aws/developer-tools/snapshots/cli-commands/ /aws/developer-tools/running-localstack/lstk/#snapshot 301 +/aws/developer-tools/snapshots/cli-commands /aws/developer-tools/running-localstack/lstk/snapshots/#snapshot 301 +/aws/developer-tools/snapshots/cli-commands/ /aws/developer-tools/running-localstack/lstk/snapshots/#snapshot 301 /aws/developer-tools/snapshots/launchpad /aws/developer-tools/snapshots/ 301 /aws/developer-tools/snapshots/launchpad/ /aws/developer-tools/snapshots/ 301 /aws/capabilities/state-management/launchpad /aws/developer-tools/snapshots/ 301 @@ -1080,8 +1080,8 @@ /aws/configuration/security-testing/iam-policy-stream /aws/developer-tools/security-testing/iam-policy-stream/ 301 /aws/configuration/security-testing/iam-policy-stream/ /aws/developer-tools/security-testing/iam-policy-stream/ 301 /aws/configuration/state-management/ /aws/developer-tools/snapshots/ 301 -/aws/configuration/state-management/cli-commands /aws/developer-tools/running-localstack/lstk/#snapshot 301 -/aws/configuration/state-management/cli-commands/ /aws/developer-tools/running-localstack/lstk/#snapshot 301 +/aws/configuration/state-management/cli-commands /aws/developer-tools/running-localstack/lstk/snapshots/#snapshot 301 +/aws/configuration/state-management/cli-commands/ /aws/developer-tools/running-localstack/lstk/snapshots/#snapshot 301 /aws/configuration/state-management/cloud-pods /aws/developer-tools/snapshots/cloud-pods/ 301 /aws/configuration/state-management/cloud-pods/ /aws/developer-tools/snapshots/cloud-pods/ 301 /aws/configuration/state-management/export-import-state /aws/developer-tools/snapshots/saving-snapshots-locally/ 301 diff --git a/src/content/docs/aws/ci-pipelines/best-practices.mdx b/src/content/docs/aws/ci-pipelines/best-practices.mdx index 399ed3b5..cce9eb9d 100644 --- a/src/content/docs/aws/ci-pipelines/best-practices.mdx +++ b/src/content/docs/aws/ci-pipelines/best-practices.mdx @@ -94,7 +94,7 @@ env = ["ci"] # Apply the [env.ci] profile below DEBUG = "1" ``` -See the [configuration reference](/aws/developer-tools/running-localstack/lstk/#configuration) for every available field. +See the [configuration reference](/aws/developer-tools/running-localstack/lstk/configuration/) for every available field. Keep a single `.lstk/config.toml` for local development and CI where you can. However, if a CI job needs different settings, pass an alternative file with `lstk --config ./ci/lstk.toml start`. @@ -112,7 +112,7 @@ It pulls the container image if needed, validates your license, starts the conta If startup fails, the command exits with a non-zero return code, causing your CI job to fail. For machine-readable output, add the global `--json` flag to any command. -See [structured output](/aws/developer-tools/running-localstack/lstk/#structured-output) and [exit codes](/aws/developer-tools/running-localstack/lstk/#exit-codes) if your pipeline needs to inspect results programmatically. +See [structured output](/aws/developer-tools/running-localstack/lstk/automation/#structured-output) and [exit codes](/aws/developer-tools/running-localstack/lstk/automation/#exit-codes) if your pipeline needs to inspect results programmatically. ## Seed state from Infrastructure as Code diff --git a/src/content/docs/aws/ci-pipelines/codebuild.md b/src/content/docs/aws/ci-pipelines/codebuild.md index da4a04ae..bf59b7cc 100644 --- a/src/content/docs/aws/ci-pipelines/codebuild.md +++ b/src/content/docs/aws/ci-pipelines/codebuild.md @@ -76,7 +76,7 @@ phases: ... ``` -Settings that apply to every run belong in an [`[env.*]` profile](/aws/developer-tools/running-localstack/lstk/#configuration) in a `.lstk/config.toml` committed to your repository, which also lets you pin the image tag. +Settings that apply to every run belong in an [`[env.*]` profile](/aws/developer-tools/running-localstack/lstk/configuration/) in a `.lstk/config.toml` committed to your repository, which also lets you pin the image tag. Read more about the [configuration options](/aws/customization/configuration-options) of LocalStack. ### Dump LocalStack logs @@ -192,7 +192,7 @@ cache: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit ``` - To resolve this, either use your Docker Hub account credentials to pull the image, or point `lstk` at LocalStack's public ECR mirror with the [`image` field](/aws/developer-tools/running-localstack/lstk/#custom-container-image) in `.lstk/config.toml`: + To resolve this, either use your Docker Hub account credentials to pull the image, or point `lstk` at LocalStack's public ECR mirror with the [`image` field](/aws/developer-tools/running-localstack/lstk/configuration/#custom-container-image) in `.lstk/config.toml`: ```toml [[containers]] diff --git a/src/content/docs/aws/ci-pipelines/github-actions.md b/src/content/docs/aws/ci-pipelines/github-actions.md index e739ee38..fb5230df 100644 --- a/src/content/docs/aws/ci-pipelines/github-actions.md +++ b/src/content/docs/aws/ci-pipelines/github-actions.md @@ -46,7 +46,7 @@ You can then install `lstk` and start the emulator, passing the secret to the st ``` `lstk start` pulls the image, validates your license, and returns only once the emulator is ready, so no separate wait step is needed. -To pin the image tag, commit a [`.lstk/config.toml`](/aws/developer-tools/running-localstack/lstk/#configuration) to your repository rather than passing it on the command line. +To pin the image tag, commit a [`.lstk/config.toml`](/aws/developer-tools/running-localstack/lstk/configuration/) to your repository rather than passing it on the command line. Where several steps run `lstk`, set `LOCALSTACK_AUTH_TOKEN` once at the job level instead of repeating it on every step. `lstk setup aws` writes a `localstack` AWS profile for the runner's `aws` binary to use. It is optional, but without it `lstk` notes on every call that no profile was found. @@ -65,7 +65,7 @@ For example: ``` You can add extra configuration options as further `LOCALSTACK_`-prefixed variables. -Settings that apply to every run belong in an [`[env.*]` profile](/aws/developer-tools/running-localstack/lstk/#configuration) in `.lstk/config.toml` instead. +Settings that apply to every run belong in an [`[env.*]` profile](/aws/developer-tools/running-localstack/lstk/configuration/) in `.lstk/config.toml` instead. ### Dump Localstack logs diff --git a/src/content/docs/aws/connecting/infrastructure-as-code/aws-cdk.md b/src/content/docs/aws/connecting/infrastructure-as-code/aws-cdk.md index 48e103a2..934ceb76 100644 --- a/src/content/docs/aws/connecting/infrastructure-as-code/aws-cdk.md +++ b/src/content/docs/aws/connecting/infrastructure-as-code/aws-cdk.md @@ -14,7 +14,7 @@ The AWS Cloud Development Kit (CDK) is an Infrastructure-as-Code (IaC) tool usin ## AWS CDK CLI for LocalStack -[`lstk cdk`](/aws/developer-tools/running-localstack/lstk/#cdk) proxies the [AWS CDK](https://github.com/aws/aws-cdk) library against local APIs provided by LocalStack. It requires the AWS CDK CLI version `2.177.0` or newer on your `PATH`. +[`lstk cdk`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#cdk) proxies the [AWS CDK](https://github.com/aws/aws-cdk) library against local APIs provided by LocalStack. It requires the AWS CDK CLI version `2.177.0` or newer on your `PATH`. :::note `lstk cdk` supersedes the older [`cdklocal` wrapper script](/aws/connecting/infrastructure-as-code/deprecated-wrapper-scripts#cdklocal), which is deprecated but still available if you need it. @@ -75,7 +75,7 @@ lstk cdk deploy > Do you wish to deploy these changes (y/n)? y ``` -Once the deployment is done, you can inspect the created resources via the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command line +Once the deployment is done, you can inspect the created resources via the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command line ```bash lstk aws sns list-topics diff --git a/src/content/docs/aws/connecting/infrastructure-as-code/aws-sam.md b/src/content/docs/aws/connecting/infrastructure-as-code/aws-sam.md index 5b380786..edb114ba 100644 --- a/src/content/docs/aws/connecting/infrastructure-as-code/aws-sam.md +++ b/src/content/docs/aws/connecting/infrastructure-as-code/aws-sam.md @@ -12,7 +12,7 @@ The AWS Serverless Application Model (SAM) is an open-source framework for devel It uses a simplified syntax to define functions, APIs, databases, and event source mappings. When you deploy, SAM converts its syntax into AWS CloudFormation syntax, helping you create serverless applications more quickly. -LocalStack can work with SAM using [`lstk sam`](/aws/developer-tools/running-localstack/lstk/#sam), which lets you deploy SAM applications on LocalStack. +LocalStack can work with SAM using [`lstk sam`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#sam), which lets you deploy SAM applications on LocalStack. This guide explains how to set up local AWS resources using `lstk sam`. ## `lstk sam` diff --git a/src/content/docs/aws/connecting/infrastructure-as-code/cloud-custodian.md b/src/content/docs/aws/connecting/infrastructure-as-code/cloud-custodian.md index cdff1fb8..838498f5 100644 --- a/src/content/docs/aws/connecting/infrastructure-as-code/cloud-custodian.md +++ b/src/content/docs/aws/connecting/infrastructure-as-code/cloud-custodian.md @@ -16,7 +16,7 @@ You can use Cloud Custodian with LocalStack by just specifying the Cloud Custodi ## Getting started -This guide is designed for users who are new to Cloud Custodian and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users who are new to Cloud Custodian and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can spin up an EC2 instance and tag it with the key `Custodian`, and then use Cloud Custodian to stop the instance. diff --git a/src/content/docs/aws/connecting/infrastructure-as-code/crossplane.md b/src/content/docs/aws/connecting/infrastructure-as-code/crossplane.md index 42b1c1f4..9420611c 100644 --- a/src/content/docs/aws/connecting/infrastructure-as-code/crossplane.md +++ b/src/content/docs/aws/connecting/infrastructure-as-code/crossplane.md @@ -194,7 +194,7 @@ crossplane-test-bucket True True crossplane-test-bucket 30s ``` ... -and the bucket it should also be visible when querying the local S3 buckets in LocalStack via [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws): +and the bucket it should also be visible when querying the local S3 buckets in LocalStack via [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws): ```bash lstk aws s3 ls diff --git a/src/content/docs/aws/connecting/infrastructure-as-code/former2.md b/src/content/docs/aws/connecting/infrastructure-as-code/former2.md index a766f24d..0e0dc2ed 100644 --- a/src/content/docs/aws/connecting/infrastructure-as-code/former2.md +++ b/src/content/docs/aws/connecting/infrastructure-as-code/former2.md @@ -26,7 +26,7 @@ These outputs enable you to redeploy your resources while spinning a new LocalSt ## Getting started -This guide is designed for users new to Former2 and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Former2 and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. We will demonstrate how you can create local AWS resources using LocalStack, and import a CloudFormation output via Former2. ### Install Former2 diff --git a/src/content/docs/aws/connecting/infrastructure-as-code/terraform.mdx b/src/content/docs/aws/connecting/infrastructure-as-code/terraform.mdx index 9f645cdc..5b6597d7 100644 --- a/src/content/docs/aws/connecting/infrastructure-as-code/terraform.mdx +++ b/src/content/docs/aws/connecting/infrastructure-as-code/terraform.mdx @@ -17,7 +17,7 @@ HCL is a domain-specific language designed for writing configurations that defin LocalStack supports Terraform via the [AWS provider](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) through [custom service endpoints](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/custom-service-endpoints#localstack). You can configure Terraform to use LocalStack in two ways: -- Using [`lstk terraform`](/aws/developer-tools/running-localstack/lstk/#terraform) (alias `lstk tf`) to automatically configure the service endpoints for you. +- Using [`lstk terraform`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#terraform) (alias `lstk tf`) to automatically configure the service endpoints for you. - Manually configuring the service endpoints in your Terraform configuration with additional maintenance. In this guide, we will demonstrate how you can create local AWS resources using Terraform and LocalStack, by using `lstk terraform` and a manual configuration example. diff --git a/src/content/docs/aws/customization/advanced/filesystem.mdx b/src/content/docs/aws/customization/advanced/filesystem.mdx index 14a71fd6..616e259b 100644 --- a/src/content/docs/aws/customization/advanced/filesystem.mdx +++ b/src/content/docs/aws/customization/advanced/filesystem.mdx @@ -113,4 +113,4 @@ volume = "./volume" ``` If `volume` is not set, `lstk` defaults to `/lstk/volume/`. -Run [`lstk volume path`](/aws/developer-tools/running-localstack/lstk#volume) to print the resolved directory. +Run [`lstk volume path`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#volume) to print the resolved directory. diff --git a/src/content/docs/aws/customization/configuration-options.md b/src/content/docs/aws/customization/configuration-options.md index 2495183c..d0f29213 100644 --- a/src/content/docs/aws/customization/configuration-options.md +++ b/src/content/docs/aws/customization/configuration-options.md @@ -28,7 +28,7 @@ DEBUG = "1" lstk start ``` -See [Passing environment variables to the container](/aws/developer-tools/running-localstack/lstk#passing-environment-variables-to-the-container) for details. +See [Passing environment variables to the container](/aws/developer-tools/running-localstack/lstk/configuration/#passing-environment-variables-to-the-container) for details. To facilitate interoperability, configuration variables can be prefixed with `LOCALSTACK_` in docker. For instance, setting `LOCALSTACK_PERSISTENCE=1` is equivalent to `PERSISTENCE=1`. @@ -61,7 +61,7 @@ Options that affect the core LocalStack system. ## CLI `lstk` is configured through its config file rather than through environment variables. -See [Configuration](/aws/developer-tools/running-localstack/lstk#configuration) on the `lstk` page for the config file search order, the field reference, and how to define named environment profiles. +See [Configuration](/aws/developer-tools/running-localstack/lstk/configuration/) on the `lstk` page for the config file search order, the field reference, and how to define named environment profiles. ## Docker diff --git a/src/content/docs/aws/customization/kubernetes/openshift.md b/src/content/docs/aws/customization/kubernetes/openshift.md index 767245b1..9930a12f 100644 --- a/src/content/docs/aws/customization/kubernetes/openshift.md +++ b/src/content/docs/aws/customization/kubernetes/openshift.md @@ -23,7 +23,7 @@ If you have any questions or uncertainties regarding the licensing implications, ## Getting started -This guide is designed for users new to LocalStack and assumes basic knowledge of the AWS CLI and our [`lstk aws` AWS CLI proxy](/aws/developer-tools/running-localstack/lstk#aws). +This guide is designed for users new to LocalStack and assumes basic knowledge of the AWS CLI and our [`lstk aws` AWS CLI proxy](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws). As a general prerequisite, you should have access to the [OpenShift Web Console](https://docs.openshift.com/container-platform/4.14/web_console/web-console-overview.html). We will demonstrate how you can create local AWS resources using LocalStack using the AWS CLI. @@ -93,7 +93,7 @@ Since we are running LocalStack on OpenShift, we need to specify the route URL o The flag takes precedence over the environment variable. ::: -You can further use the other `lstk` tool proxies, such as [`lstk cdk`](/aws/developer-tools/running-localstack/lstk#cdk), [`lstk sam`](/aws/developer-tools/running-localstack/lstk#sam), and [`lstk terraform`](/aws/developer-tools/running-localstack/lstk#terraform), to interact with the deployment. +You can further use the other `lstk` tool proxies, such as [`lstk cdk`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#cdk), [`lstk sam`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#sam), and [`lstk terraform`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#terraform), to interact with the deployment. As with `lstk aws`, set `LSTK_ENDPOINT_URL` or pass `--endpoint-url` to point these at the route URL instead of a local emulator. ### Deleting the LocalStack deployment diff --git a/src/content/docs/aws/customization/other-installations/enterprise-image.md b/src/content/docs/aws/customization/other-installations/enterprise-image.md index 15900e62..a32c4c3d 100644 --- a/src/content/docs/aws/customization/other-installations/enterprise-image.md +++ b/src/content/docs/aws/customization/other-installations/enterprise-image.md @@ -39,7 +39,7 @@ This offline functionality is enabled by: lstk start ``` - See [Custom container image](/aws/developer-tools/running-localstack/lstk#custom-container-image) for details, including how `lstk` falls back to a locally present image when a pull fails. + See [Custom container image](/aws/developer-tools/running-localstack/lstk/configuration/#custom-container-image) for details, including how `lstk` falls back to a locally present image when a pull fails. ## "Online" vs "Offline" image diff --git a/src/content/docs/aws/developer-tools/running-localstack/lstk.mdx b/src/content/docs/aws/developer-tools/running-localstack/lstk.mdx deleted file mode 100644 index 24f36b6b..00000000 --- a/src/content/docs/aws/developer-tools/running-localstack/lstk.mdx +++ /dev/null @@ -1,1577 +0,0 @@ ---- -title: lstk CLI -description: Reference guide for lstk, the modern CLI for managing LocalStack, with installation, configuration, commands, and troubleshooting. -template: doc -sidebar: - order: 10 -tags: ['Hobby'] ---- - -import { Tabs, TabItem } from '@astrojs/starlight/components'; - -## Introduction - -`lstk` is a high-performance command-line interface for LocalStack, built in Go. -It provides a built-in terminal UI (TUI) for interactive use and plain text output for CI/CD pipelines and scripting. - -`lstk` handles the full emulator lifecycle: authentication, pulling the Docker image, starting, stopping, and restarting the container, streaming logs, and checking status. -It can also save and load emulator state (as local snapshots or Cloud Pods) reset running state, run AWS CLI commands against the emulator, and manage the on-disk volume. -Running `lstk` with no arguments takes you through the entire startup flow automatically. - -`lstk` also proxies developer tools so they run directly against LocalStack: the AWS CLI (`lstk aws`), the Azure CLI (`lstk az`), Terraform (`lstk terraform`), the AWS CDK (`lstk cdk`), and the AWS SAM CLI (`lstk sam`). - -:::tip[Recommended] -`lstk` is the recommended way to run and manage LocalStack. The [legacy LocalStack CLI](/aws/developer-tools/running-localstack/localstack-cli/) is deprecated. -::: - -## Prerequisites - -- [Docker](https://docs.docker.com/get-docker/) installed and running. -- A [LocalStack account](https://www.localstack.cloud/pricing) with a [license](/aws/getting-started/auth-token/#license-assignment), and `lstk` handles authentication for you (see [Authentication](#authentication)). - -## Installation - - - - -```bash -brew install localstack/tap/lstk -``` - -Homebrew also installs shell completions for bash, zsh, and fish automatically. - - - - -```bash -npm install -g @localstack/lstk -``` - - - - -Download the binary for your platform from [GitHub Releases](https://github.com/localstack/lstk/releases), extract it, and place it on your `PATH`. - - - - -Verify the installation: - -```bash -lstk --version -``` - -### Updating - -`lstk` can update itself. -It detects how it was originally installed (Homebrew, npm, or binary) and uses the matching update method: - -```bash -# Check for updates without installing -lstk update --check - -# Update to the latest version -lstk update -``` - -See the [`update`](#update) command for details, including the start-time update notification. - -## Quick start - -```bash -lstk -``` - -Running `lstk` without arguments performs the full startup sequence: authenticates you automatically, pulls the latest image if needed, and starts the LocalStack container. -In an interactive terminal it launches the TUI; in a non-interactive environment it prints plain text output. - -On the very first interactive run, `lstk` prompts you to pick which emulator to run (AWS, Snowflake, or Azure) and writes your choice to `config.toml`. -See [Emulator types](#emulator-types) for the available options. - -For CI or headless environments, set `LOCALSTACK_AUTH_TOKEN` and use `--non-interactive`: - -```bash -LOCALSTACK_AUTH_TOKEN= lstk --non-interactive -``` - -CI environments require a CI Auth Token; a personal Developer Auth Token cannot be used there. - -## Authentication - -`lstk` resolves your auth token in the following order: - -1. **System keyring**: a token stored by a previous `lstk login`. -2. **`LOCALSTACK_AUTH_TOKEN` environment variable**: used only when the keyring has no token. -3. **Browser login**: triggered automatically in interactive mode when neither of the above provides a token. - -:::caution -The keyring token takes precedence over `LOCALSTACK_AUTH_TOKEN`. -If you set or change the environment variable but a keyring token already exists, the environment variable is ignored. -Run `lstk logout` to clear the stored keyring token first. -::: - -### Logging in - -```bash -lstk login -``` - -Opens a browser window for authentication and stores the resulting token in your system keyring. -This command requires an interactive terminal. -See the [`login`](#login) command for the full flow and the endpoints it uses. - -### Logging out - -```bash -lstk logout -``` - -Removes the stored credentials from the system keyring and the file-based fallback, and clears the cached license. -`logout` cannot clear a token supplied via `LOCALSTACK_AUTH_TOKEN`; if you authenticated that way, unset the variable instead. -See the [`logout`](#logout) command for the full behavior. - -### File-based token storage - -On systems where the system keyring is unavailable, `lstk` automatically falls back to storing the token in a file (`/auth-token`, mode `0600`). -You can force file-based storage by setting: - -```bash -export LSTK_KEYRING=file -``` - -## Configuration - -`lstk` uses a TOML configuration file, created automatically on first run. - -### Config file search order - -`lstk` uses the first `config.toml` it finds in this order: - -1. `./.lstk/config.toml`: project-local config in the current directory. -2. `$HOME/.config/lstk/config.toml`: user config (created here if `$HOME/.config/` exists). -3. OS default: - - **macOS**: `$HOME/Library/Application Support/lstk/config.toml` - - **Windows**: `%AppData%\lstk\config.toml` - - **Linux**: `$XDG_CONFIG_HOME/lstk/config.toml` or `$HOME/.config/lstk/config.toml` - -On first run, the config is created at path #2 if `$HOME/.config/` already exists; otherwise at the OS default (#3). - -To see the active config file path: - -```bash -lstk config path -``` - -To use a specific config file: - -```bash -lstk --config /path/to/config.toml start -``` - -### Default configuration - -The default `config.toml` created on first run: - -```toml -[[containers]] -type = "aws" # Emulator type. Supported: "aws", "snowflake", "azure" -tag = "latest" # Docker image tag, e.g. "latest", "2026.4" -port = "4566" # Host port the emulator will be accessible on -# image = "" # Full image override (e.g. an internal mirror or offline image) -# volume = "" # Host directory for persistent state (default: OS cache dir) -# volumes = [] # Docker-style "host:container[:ro]" bind mounts (see Volumes) -# env = [] # Named environment profiles to apply (see [env.*] sections below) -# snapshot = "" # Snapshot REF to auto-load after start (AWS only) -``` - -### Config field reference - -| Field | Type | Default | Description | -|:-----------|:---------|:-----------|:-----------------------------------------------------------------------------------------------------| -| `type` | string | `"aws"` | Emulator type. One of `"aws"`, `"snowflake"`, `"azure"`. Run a single `[[containers]]` block at a time. See [Emulator types](#emulator-types). | -| `tag` | string | `"latest"` | Docker image tag (`"latest"`, `"2026.4"`, etc.). Useful for pinning a specific version. Zero-padded months (`"2026.04"`) are normalized to `"2026.4"`. | -| `port` | string | `"4566"` | Host port the emulator listens on (1–65535). The in-container port is always `4566`. | -| `image` | string | (default) | Full image reference that overrides the default Docker Hub image, e.g. an internal-registry mirror or a locally loaded offline image. If it already carries a tag, `tag` is ignored; otherwise `tag` (or `latest`) is appended. | -| `volume` | string | (OS cache) | Host directory for persistent emulator state. Defaults to `/lstk/volume/`. See also `volumes`. | -| `volumes` | string[] | `[]` | Docker-style `"host:container[:ro]"` bind mounts (e.g. init hooks). May also carry the persistence mount (target `/var/lib/localstack`). See [Volume mounts](#volume-mounts). | -| `env` | string[] | `[]` | List of named environment profiles to inject into the container (see below). | -| `snapshot` | string | `""` | Snapshot REF (e.g. `pod:my-baseline` or a local path) to auto-load after the emulator starts. AWS emulator only. See [Auto-loading a snapshot on start](#auto-loading-a-snapshot-on-start). | - -:::note -There is no `update_prompt` config key. -`lstk` always checks for available updates on startup. -Once you choose to skip a version, `lstk` records it under the `[cli]` table as `update_skipped_version` and stops prompting for that version. -This value is written automatically and is not meant to be hand-edited (see [`update`](#update)). -::: - -### Emulator types - -`lstk` can run more than one kind of emulator. -The `type` field in your `config.toml` selects which one: - -| Type | Docker image | Description | -|:------------|:------------------------------|:-------------------------------------| -| `aws` | `localstack/localstack-pro` | LocalStack AWS emulator (default). | -| `snowflake` | `localstack/snowflake` | LocalStack Snowflake emulator. | -| `azure` | `localstack/localstack-azure` | LocalStack Azure emulator. | - -On the first interactive run, `lstk` prompts you to pick an emulator (`a` for AWS, `s` for Snowflake, `z` for Azure) and writes your choice to `config.toml`. -In non-interactive mode the default `aws` emulator is used if no config file is found. - -Lifecycle commands operate on the emulators defined in your `config.toml`. -Run a single `[[containers]]` block at a time; the AWS-specific commands (`status` resources, `aws`, `reset`, `setup aws`) require an `aws` emulator to be configured. - -:::note -The AWS emulator's license is validated by `lstk` before the container starts. -The Snowflake and Azure emulators validate their own license inside the container at startup, so `lstk` skips its pre-flight license check for them. -If your license does not include the selected emulator, the container exits and `lstk` reports the missing entitlement. -::: - -### Passing environment variables to the container - -Define reusable environment profiles under `[env.]` and reference them in your container config: - -```toml -[[containers]] -type = "aws" -tag = "latest" -port = "4566" -env = ["debug", "ci"] - -[env.debug] -DEBUG = "1" -ENFORCE_IAM = "1" -PERSISTENCE = "1" - -[env.ci] -SERVICES = "s3,sqs" -EAGER_SERVICE_LOADING = "1" -``` - -When `lstk start` runs, the key-value pairs from each referenced profile are injected as environment variables into the LocalStack container. -Keys are uppercased automatically. - -:::note -If you reference an `env` profile name that doesn't exist in your config, `lstk` returns an error: `environment "..." referenced in container config not found`. -::: - -In addition to your custom profiles, `lstk` always injects several variables into the container. -See [Container-injected variables](#container-injected-variables) for the full list. - -### Custom container image - -By default the emulator image is pulled from Docker Hub (`localstack/localstack-pro`, `localstack/snowflake`, or `localstack/localstack-azure` depending on `type`). -Set `image` on a container block to override it — for example, to pull from an internal-registry mirror or to run a locally loaded image in an air-gapped environment: - -```toml -[[containers]] -type = "aws" -image = "registry.internal.example.com/localstack/localstack-pro" -tag = "2026.4" -``` - -If `image` already carries a tag (e.g. `...:2026.4`), the separate `tag` field is ignored; otherwise `tag` (or `latest`) is appended. -See [Offline and enterprise environments](#offline-and-enterprise-environments) for how `lstk` falls back to a locally present image when a pull fails. - -### Volume mounts - -Beyond the single persistence directory set by `volume`, a container block can declare arbitrary Docker-style bind mounts with `volumes`. -Each entry is a `"host:container[:ro]"` spec — useful, for example, for mounting a [Snowflake init hook](/snowflake/capabilities/init-hooks/) script into `/etc/localstack/init/{boot,start,ready,shutdown}.d`: - -```toml -[[containers]] -type = "snowflake" -port = "4566" -volumes = [ - "./test.sf.sql:/etc/localstack/init/ready.d/test.sf.sql", - "./data:/var/lib/localstack", -] -``` - -- A `volumes` entry whose container target is `/var/lib/localstack` sets the persistence directory (the same mount `volume` configures); this is what [`lstk volume path`](#volume) and [`lstk volume clear`](#volume) resolve. -- Relative host sources and a leading `~/` are resolved against the config file's directory. This differs from the legacy `volume` field, whose value is passed to Docker verbatim. -- Setting the persistence directory through both `volume` and a `volumes` entry with a different source is a validation error. - -`volume` and `volumes` overlap only for the persistence mount: `volume` can *only* set the persistence directory, while `volumes` is a superset that can also express init hooks and other mounts. - -### Using a project-local config - -Place a `.lstk/config.toml` in your project directory. -When you run `lstk` from that directory, the local config takes precedence over the global one. -This lets each project pin its own emulator type, image tag, and environment profiles. - -For example, a project that targets the Snowflake emulator can keep its own config: - -```toml -# .lstk/config.toml -[[containers]] -type = "snowflake" -port = "4566" -``` - -An AWS project might instead pin a specific image tag and enable a debug profile: - -```toml -# .lstk/config.toml -[[containers]] -type = "aws" -tag = "2026.4" -port = "4566" -env = ["dev"] - -[env.dev] -DEBUG = "1" -PERSISTENCE = "1" -``` - -## Commands - -`lstk` uses a flat command structure. -Running `lstk` with no command is equivalent to `lstk start`. - -### `start` - -Start the LocalStack emulator. -Launches the TUI in interactive terminals and prints plain output otherwise. -`lstk start` launches the emulator defined in the first `[[containers]]` entry of the resolved `config.toml` (not necessarily AWS). - -```bash -lstk start -lstk start --persist -lstk start --non-interactive -``` - -| Option | Description | -|:--------------------|:-----------------------------------------------------------------------------| -| `--persist` | Persist emulator state across restarts (sets `LOCALSTACK_PERSISTENCE=1` in the container) | -| `--type `, `-t ` | Select the emulator to start (`aws`, `snowflake`, or `azure`) non-interactively, recording the choice in `config.toml`. See [Selecting the emulator with `--type`](#selecting-the-emulator-with---type). | -| `--snapshot ` | Auto-load this snapshot after the emulator starts, overriding the configured `snapshot` for one run (AWS only) | -| `--no-snapshot` | Skip auto-loading the configured `snapshot` for this run | -| `--timeout ` | Maximum time to wait for the emulator to become ready, as a Go duration (e.g. `90s`, `2m`). Overrides `LSTK_STARTUP_TIMEOUT` for this run; `0` uses the per-mode default. | -| `--non-interactive` | Disable the interactive TUI and use plain output | - -`lstk start` forwards host environment variables prefixed with `LOCALSTACK_` to the emulator (the host `LOCALSTACK_AUTH_TOKEN` is dropped so it cannot override the token `lstk` resolved). See [Container-injected variables](#container-injected-variables). - -`lstk` applies a readiness deadline while waiting for the emulator to come up (a crash during startup is detected instantly, with its exit code, and does not wait for the deadline). In an interactive terminal the deadline defaults to 20 seconds and is only a recoverable prompt — you can keep waiting or stop; in non-interactive mode it defaults to 60 seconds and is fatal, leaving the container running for inspection. Override the deadline for a single run with `--timeout` (a Go duration such as `90s` or `2m`), or for every run with [`LSTK_STARTUP_TIMEOUT`](#environment-variables); an explicit `--timeout` wins over the environment variable, and `--timeout 0` falls back to the per-mode default. The flag is available on `start` and the bare `lstk` command only — `restart` and the snapshot auto-start path do not expose it. - -By default the emulator starts with a fresh state on every run. -Pass `--persist` to keep data across restarts: `lstk` injects `LOCALSTACK_PERSISTENCE=1` into the container so state is written to the mounted [`volume`](#config-field-reference) and reloaded on the next start. -When persistence is active, the AWS emulator's startup summary includes a `• Persistence: Enabled` line. - -```bash -# Start with persistent state -lstk start --persist -``` - -:::note -`--persist` is a flag on `start` (and the bare `lstk` command) and on [`restart`](#restart). -For finer-grained control, you can also set `PERSISTENCE = "1"` in an environment profile (see [Passing environment variables to the container](#passing-environment-variables-to-the-container)). -::: - -#### Selecting the emulator with `--type` - -`--type` (shorthand `-t`, also available on the bare `lstk` command) is the non-interactive answer to the first-run emulator picker. -It selects which emulator to start (`aws`, `snowflake`, or `azure`) and **records the choice in `config.toml`**, so lifecycle commands (`stop`, `status`, `logs`, `volume`, snapshot auto-load) stay in sync with what you started. - -```bash -# Start the Snowflake emulator, recording the choice in config -lstk start --type snowflake - -# Shorthand -lstk start -t azure -``` - -- On first run, the config is created with the selected type. -- If the configured type already matches, `--type` is a no-op. -- If it differs, `lstk` rewrites the `type` line in place (comments and formatting preserved) and prints a note naming the config file. - -When switching an existing config to a different type: - -- A custom `image` is a **hard error** — it pins a specific product that cannot be reinterpreted under a new emulator type. Use a separate config (`--config`) for that profile instead. -- A non-`latest` `tag` and any `volume`/`volumes` mounts are kept, but `lstk` warns that they may be product-specific. -- `port`, `env`, and `snapshot` are kept silently. - -`--type` is a flag only; passing the emulator as a positional (`lstk start azure`) is rejected with a hint pointing at `--type`. - -#### Auto-loading a snapshot on start - -For the **AWS emulator**, you can have `lstk` load a snapshot automatically every time it starts the emulator. -Set the `snapshot` field on the container block to any load REF (a `pod:` Cloud Pod or a local path): - -```toml -[[containers]] -type = "aws" -port = "4566" -snapshot = "pod:my-baseline" -``` - -The snapshot is loaded only when the emulator is **freshly started** this run; if it is already running, the auto-load is skipped. -Override it for a single run with `--snapshot REF`, or skip it entirely with `--no-snapshot`: - -```bash -# Start and load a different snapshot for this run only -lstk start --snapshot pod:other-baseline - -# Start without loading the configured snapshot -lstk start --no-snapshot -``` - -The `snapshot` field is only read on start; [`snapshot save`](#snapshot-save) never writes it back into your config. - -### `stop` - -Stop the running LocalStack emulator. -Stops every emulator container defined in the resolved `config.toml` (the `[[containers]]` entries), with a 30-second stop timeout per container. - -```bash -lstk stop -lstk stop --non-interactive -``` - -`stop` fails fast if the Docker runtime is not healthy (for example, Docker is not running), or if a configured emulator is not currently running (`LocalStack is not running`). -In an interactive terminal it shows an animated "Stopping LocalStack..." spinner and a styled confirmation; in non-interactive mode it prints the same progress and result as plain text. - -`stop` supports [`--json`](#structured-output): the `data` payload lists each configured emulator and whether it `wasRunning`. - -### `restart` - -Stop and restart the LocalStack emulator. -Performs a stop of the running emulator followed by a fresh start, using the same auth, config, and Docker settings as [`start`](#start). -Launches the TUI in interactive terminals and prints plain output otherwise. - -```bash -lstk restart -lstk restart --persist -``` - -| Option | Description | -|:-------------|:-------------------------------------------| -| `--persist` | Persist emulator state across the restart | - -By default, emulator state is **not** retained across the restart and the container starts clean. -Pass `--persist` to keep the emulator's state so it survives the restart. - -### `status` - -Show the status of a running emulator and its deployed resources. -Before contacting the emulator, `lstk` checks that the Docker runtime is healthy; if it is not, the command reports `runtime not healthy` and exits with a non-zero status. - -```bash -lstk status -lstk --non-interactive status -``` - -For each emulator configured in your `config.toml` (the `[[containers]]` entries), `status` reports whether it is running and, if so, prints an instance summary: - -```text -LocalStack AWS Emulator is running -• Endpoint: localhost:4566 -• Persistence: Enabled -• Container: localstack-aws -• Version: 4.0.0 -• Uptime: 1h 12m 4s -``` - -- **Endpoint** is the live `host:port`, queried from Docker, so it stays correct even if the configured `port` was changed while the container kept running. -- **Persistence** appears only for the AWS emulator and only when persistence is enabled. -- **Uptime** is computed from the container's start time and is omitted if it cannot be determined. - -If an emulator is not running, `status` prints an error and exits non-zero without checking the remaining emulators: - -```text -LocalStack AWS Emulator is not running - - Start LocalStack: lstk - See help: lstk -h -``` - -For the **AWS emulator**, `status` additionally lists deployed resources. -When resources exist it prints a summary line followed by a table; when none exist it prints `No resources deployed`. - -```text -~ 3 resources · 2 services - -Service Resource Region Account -S3 my-bucket us-east-1 000000000000 -SQS my-queue us-east-1 000000000000 -``` - -In an interactive terminal the output is rendered through the TUI; in non-interactive mode (or with `--non-interactive`) the same content is printed as plain text, with the resource table shown at full width when stdout is not a TTY. -The Snowflake and Azure emulators show the instance summary only and never report resources. - -### `logs` - -Show or stream emulator logs. - -```bash -lstk logs [options] -``` - -| Option | Description | -|:------------|:-----------------------------------------| -| `--follow`, `-f` | Stream logs in real-time. Without this flag, `lstk` prints the currently available logs and exits. | -| `--verbose`, `-v` | Show all logs without filtering. By default, `lstk` drops noisy lines (internal request logs, provider chatter); `--verbose` shows every line verbatim. | -| `--tail `, `-n ` | Show only the last `N` lines from the end of the logs. Accepts a non-negative integer or `all` (the default, showing all available lines). | - -By default, `lstk logs` reads from the first configured emulator container and applies a noise filter. -In an interactive terminal, lines are color-coded by log level (`DEBUG`, `INFO`, `WARN`, `ERROR`); in non-interactive mode, raw log lines are written to stdout. - -Example: - -```bash -# Print current filtered logs and exit -lstk logs - -# Stream filtered logs in real-time -lstk logs --follow - -# Show only the last 100 lines -lstk logs --tail 100 - -# Stream all logs without filtering -lstk logs --follow --verbose -``` - -### `aws` - -Run AWS CLI commands against the running LocalStack emulator. -`lstk aws` proxies your host `aws` CLI with the endpoint, credentials, and region pre-configured, so you don't have to pass `--endpoint-url` or set test credentials yourself. - -```bash -lstk aws s3 ls -lstk aws sqs list-queues -lstk aws s3 mb s3://my-bucket -``` - -It is equivalent to running: - -```bash -aws --endpoint-url http://localhost:4566 -``` - -with `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_DEFAULT_REGION` set automatically. - -Everything after `lstk aws` is forwarded verbatim to the host `aws` binary, including AWS CLI flags such as `--region` or `--output`. -The exit code and `stdout`/`stderr` of the underlying `aws` process are passed through unchanged, so piping and interactive subcommands work as expected. - -| Option | Description | -|:--------------------|:--------------------------------------------------------------------------------------------------| -| `--non-interactive` | Suppress the loading spinner. Unlike other commands, this flag is stripped before invoking `aws` (not forwarded). | - -:::note -`lstk aws` does not start the emulator. -The AWS emulator must already be running (`lstk start`), Docker must be healthy, and the host `aws` CLI must be installed and on your `PATH`. -::: - -#### Credentials and region - -`lstk aws` injects credentials in one of two ways: - -- **Profile mode**: if a complete `localstack` profile exists in both `~/.aws/config` and `~/.aws/credentials`, `lstk` appends `--profile localstack` and lets `aws` read the region, credentials, and endpoint from that profile. -- **Profile-less mode**: if the profile is not present, `lstk` runs `aws` with `AWS_ACCESS_KEY_ID=test`, `AWS_SECRET_ACCESS_KEY=test`, and `AWS_DEFAULT_REGION=us-east-1` injected only when those variables are not already set in your environment. In this mode it also prints an informational note: `No AWS profile found, run 'lstk setup aws'`. - -Run [`lstk setup aws`](#setup) to create the `localstack` profile for use with the AWS CLI and SDKs. - -#### Endpoint resolution - -By default, `lstk` probes whether `localhost.localstack.cloud` resolves to `127.0.0.1` and uses `localhost.localstack.cloud:` if so, otherwise it falls back to `127.0.0.1:`. -Set [`LOCALSTACK_HOST`](#environment-variables) to override the host:port used to reach LocalStack and skip the DNS probe. -The port comes from the AWS container's `port` in `config.toml` (default `4566`). - -### `az` - -Run Azure CLI commands against the running LocalStack Azure emulator. -`lstk az` runs `az` with an isolated `AZURE_CONFIG_DIR` in which a custom Azure cloud is registered against LocalStack's endpoints, so your global `~/.azure` configuration is left untouched and plain `az` keeps talking to real Azure. - -Run [`lstk setup azure`](#setup-azure) once before using this mode. -Everything after `lstk az` is forwarded verbatim to the host `az` binary, and its exit code and output are passed through unchanged. - -```bash -lstk az group list -lstk az storage account list -``` - -The Azure CLI has no `--endpoint-url`/`--profile` equivalent, so the isolation relies entirely on the dedicated config directory prepared by `setup azure`. - -#### Global interception (optional) - -If a script must invoke plain `az` (not `lstk az`), you can redirect your **global** `~/.azure` to LocalStack instead: - -```bash -# Point global 'az' at the LocalStack Azure emulator -lstk az start-interception - -# Switch back to real Azure -lstk az stop-interception -``` - -`start-interception` registers and activates the `LocalStack` cloud in your global Azure configuration so every `az` invocation targets LocalStack until you stop it. -`stop-interception` switches the active cloud back to `AzureCloud` (override with `--cloud `) and re-enables instance discovery, but only when `LocalStack` is still the active cloud, to avoid clobbering an unrelated selection. - -:::caution -Interception changes global state that affects every `az` command in any terminal. -Use the isolated `lstk az ` mode unless you specifically need plain `az` to target LocalStack. -::: - -### `terraform` - -Run Terraform against LocalStack, using LocalStack endpoints as AWS provider overrides. -`lstk terraform` (alias `lstk tf`) generates a provider-override file and forwards your arguments to the real `terraform` binary. - -:::note -`lstk terraform` targets the AWS emulator. -To use Terraform with the other emulators, see the relevant emulator docs. -::: - -```bash -lstk terraform init -lstk terraform --region us-west-2 plan -lstk tf apply -``` - -lstk-specific flags must appear **before** the Terraform action: - -| Option | Default | Description | -|:------------------|:---------------------|:---------------------------------------| -| `--region ` | `us-east-1` | Deployment region. | -| `--account ` | `test` | Target AWS account id (12 digits). | - -Relevant environment variables: `AWS_ENDPOINT_URL` (override the auto-resolved endpoint), `LSTK_TF_CMD` (binary to invoke, e.g. `tofu`; default `terraform`), `LSTK_TF_OVERRIDE_FILE_NAME` (override file name; default `localstack_providers_override.tf`), `LSTK_TF_DRY_RUN` (generate the override file but do not run Terraform), `AWS_REGION` (fallback for `--region`), and `AWS_ACCESS_KEY_ID` (fallback for `--account`). - -### `cdk` - -Run the AWS CDK against LocalStack. -Requires the AWS CDK CLI version `2.177.0` or newer on your `PATH`. - -```bash -lstk cdk bootstrap -lstk cdk --region us-west-2 deploy -lstk cdk synth -``` - -The only lstk-specific flag (before the CDK action) is `--region ` (default `us-east-1`); CDK always targets the default LocalStack account `000000000000`, so there is no `--account` flag. -Relevant environment variables: `AWS_ENDPOINT_URL`, `AWS_ENDPOINT_URL_S3`, `LSTK_CDK_CMD` (default `cdk`), and `AWS_REGION`. - -### `sam` - -Run the AWS SAM CLI against LocalStack. -Requires the AWS SAM CLI version `1.95.0` or newer on your `PATH` (older versions ignore `AWS_ENDPOINT_URL` and would target real AWS). - -```bash -lstk sam build -lstk sam --region us-west-2 deploy -lstk sam validate -``` - -lstk-specific flags (before the SAM action): `--region ` (default `us-east-1`) and `--account ` (12 digits, default `000000000000`). -Relevant environment variables: `AWS_ENDPOINT_URL`, `AWS_ENDPOINT_URL_S3`, `LSTK_SAM_CMD` (default `sam`), `AWS_REGION` (fallback for `--region`), and `AWS_ACCESS_KEY_ID` (fallback for `--account`). - -:::note -Compared with `samlocal`, image/container-based Lambda (ECR) deploys and nested CloudFormation stacks are not supported; use `samlocal` for those workflows. -::: - -:::note -Like `lstk aws`, the `az`, `terraform`, `cdk`, and `sam` proxies do not start the emulator — start it first with `lstk start`. -Each requires the corresponding third-party CLI to be installed and on your `PATH`. -::: - -:::note -When you interrupt a proxied tool (for example Ctrl+C or `kill` during `lstk terraform apply`), `lstk` forwards the termination signal to the wrapped tool and waits for it to shut down cleanly rather than killing it outright, so operations like releasing a Terraform state lock can complete. The wrapped tool's real exit code is passed through unchanged. -::: - -### `snapshot` - -Manage emulator snapshots. -A snapshot captures the running emulator's state, either as a local file on disk, as a Cloud Pod on the LocalStack platform, or in your own S3 bucket. -The `snapshot` command groups five subcommands — `save`, `load`, `list`, `remove`, and `show`. The first two are also exposed as the top-level aliases `lstk save` and `lstk load`. - -:::note -Snapshots are best supported on the **AWS emulator**. -`snapshot save`/`load` (and the `save`/`load` aliases) also work for the Snowflake and Azure emulators, but their snapshot support is experimental and not fully tested — `lstk` prints a warning such as `Snapshot support for the snowflake emulator is experimental and not fully tested.` -[`reset`](#reset) remains **AWS-only** and errors out with `reset is only supported for the AWS emulator` otherwise. -::: - -#### `snapshot save` - -Save a snapshot of the running emulator's state. -The emulator must already be running; this command does **not** auto-start it. - -```bash -# Auto-named snapshot file in the current directory -lstk snapshot save - -# Save to a specific local path -lstk snapshot save ./my-snapshot - -# Save to a Cloud Pod on the LocalStack platform (requires auth) -lstk snapshot save pod:my-baseline - -# Save to your own S3 bucket (pod name is auto-generated if omitted) -lstk snapshot save my-pod s3://my-bucket/prefix - -# Limit the snapshot to a subset of services -lstk snapshot save --services s3,lambda -``` - -The optional `[destination]` argument takes one of these forms: - -| Destination | Description | -|:--------------------------------|:------------------------------------------------------------------------------------------------| -| (omitted) | Auto-generates a timestamped snapshot file in the current directory (`./snapshot--.snapshot`). | -| local path | Writes a snapshot archive to that path. The `.snapshot` extension is forced. | -| `pod:` | Saves a Cloud Pod to the LocalStack platform. Requires authentication. | -| ` s3://bucket/prefix` | Saves to your own S3 bucket. The pod name is a separate positional (auto-generated when omitted). See [S3 remotes](#s3-remotes). | - -Pod operations require an auth token (`LOCALSTACK_AUTH_TOKEN` or a prior `lstk login`); local-file snapshots do not. - -By default a snapshot captures every service's state. Pass `-s`/`--services` with a comma-separated list to limit it to a subset; this applies uniformly to local files, `pod:` Cloud Pods, and `s3://` remotes. - -| Option | Description | -|:--------------------|:----------------------------------------------------------------------------------------------| -| `--services `, `-s ` | Comma-separated list of services to include in the snapshot (all services by default). Applies to local, `pod:`, and `s3://` destinations. | -| `--profile ` | AWS profile to read S3 credentials from (used only for `s3://` destinations). Defaults to `AWS_*` env vars, then `AWS_PROFILE`. | - -#### `snapshot load` - -Load a snapshot into the emulator, **auto-starting it first** if it is not already running. - -```bash -# Load a local snapshot by path or name -lstk snapshot load my-baseline -lstk snapshot load ./checkpoint - -# Load from a Cloud Pod (requires auth) -lstk snapshot load pod:my-baseline - -# Load from your own S3 bucket (pod name is required) -lstk snapshot load my-pod s3://my-bucket/prefix - -# Control how the snapshot merges with running state -lstk snapshot load pod:my-baseline --merge=overwrite - -# Preview what a Cloud Pod load would change, without applying it -lstk snapshot load pod:my-baseline --dry-run -``` - -The `REF` argument is required and identifies a local path/name or a `pod:` Cloud Pod. -To load from S3, pass the pod name followed by an `s3://bucket/prefix` location (see [S3 remotes](#s3-remotes)). - -| Option | Description | -|:---------------------|:--------------------------------------------------------------------------------------------------------| -| `--merge ` | How the loaded state combines with running state. One of `account-region-merge` (default), `overwrite`, `service-merge`. | -| `--dry-run` | Preview the resource additions and modifications the load would produce, per service, without changing any state. Supported for `pod:` refs only; requires a running emulator (it does not auto-start one). | -| `--profile ` | AWS profile to read S3 credentials from (used only for `s3://` sources). Defaults to `AWS_*` env vars, then `AWS_PROFILE`. | - -- `account-region-merge` (default): the snapshot wins on any `(service, account, region)` overlap. -- `overwrite`: running state is reset first, then the snapshot is imported onto a clean state. -- `service-merge`: the snapshot wins per resource; non-overlapping resources are combined. - -Set [`LSTK_MERGE_STRATEGY`](#environment-variables) to change the default strategy used when `--merge` is not passed; an explicit `--merge` always wins. - -Pass `--dry-run` with a `pod:` ref to preview a load before committing to it: `lstk` queries the platform and prints, per service, how many resources the snapshot would add or modify under the chosen merge strategy, without touching running state. It is supported for `pod:` refs only (other refs are rejected) and requires the emulator to already be running, since it does not auto-start one. - -The aliases behave identically: - -```bash -lstk save pod:my-baseline -lstk load ./checkpoint -``` - -#### `snapshot list` - -List the Cloud Pod snapshots available on the LocalStack platform. -By default, only snapshots you created are listed; pass `--all` to include every snapshot in your organization. -This subcommand operates on Cloud Pods, so it requires authentication. - -```bash -# Snapshots you created -lstk snapshot list - -# Every snapshot in your organization -lstk snapshot list --all - -# List snapshots in your own S3 bucket (requires a running emulator) -lstk snapshot list s3://my-bucket/prefix -``` - -Passing an `s3://bucket/prefix` location lists snapshots stored in your own S3 bucket instead of the platform (see [S3 remotes](#s3-remotes)). Unlike the platform listing, this queries the emulator, so it requires a running emulator. - -| Option | Description | -|:-------------------|:-------------------------------------------------------------| -| `--all` | List all snapshots in your organization, not just your own. | -| `--profile ` | AWS profile to read S3 credentials from (used only with an `s3://` location). Defaults to `AWS_*` env vars, then `AWS_PROFILE`. | - -#### `snapshot remove` - -Delete a Cloud Pod snapshot from the LocalStack platform. -Only cloud snapshots (the `pod:` prefix) can be removed; local snapshots are plain files you delete yourself. -This operation cannot be undone. - -```bash -lstk snapshot remove pod:my-baseline - -# Skip the confirmation prompt (required in non-interactive mode) -lstk snapshot remove pod:my-baseline --force -``` - -The required `REF` argument must be a `pod:` Cloud Pod reference. - -| Option | Description | -|:----------|:----------------------------------------------------------------------| -| `--force` | Skip the confirmation prompt. Required when running non-interactively. | - -#### `snapshot show` - -Show metadata for a single Cloud Pod snapshot on the LocalStack platform: its name, created date, size, LocalStack version, message, the services it contains, and per-service resource counts (resource counts render only when the platform has them for that snapshot). -This subcommand is cloud-only and requires authentication. - -```bash -lstk snapshot show pod:my-baseline -``` - -The required `REF` argument must be a `pod:` Cloud Pod reference. - -#### S3 remotes - -`snapshot save`, `load`, and `list` can target a snapshot stored in your **own S3 bucket** by passing an `s3://bucket/prefix` location. -The pod name (the snapshot's identity within the bucket) is a positional separate from the `s3://` location — required for `load`, auto-generated for `save` when omitted, and unused for `list`. - -```bash -lstk snapshot save my-pod s3://my-bucket/prefix -lstk snapshot load my-pod s3://my-bucket/prefix -lstk snapshot list s3://my-bucket/prefix -``` - -Credentials follow AWS CLI precedence: `--profile ` wins, otherwise the static `AWS_ACCESS_KEY_ID`/`AWS_SECRET_ACCESS_KEY` (plus optional `AWS_SESSION_TOKEN`) environment variables, otherwise the profile named by `AWS_PROFILE`. -Only static credentials are supported (no SSO, assume-role, or `credential_process`), and credentials must never be embedded in the URL. - -`lstk` runs a pre-flight check that the target bucket exists and errors out rather than letting the emulator auto-create a bucket on a typo. -Because the transfer is performed by the emulator (not the CLI), S3 remotes require a **running emulator**, and `list s3://…` in particular queries the emulator rather than the platform API. - -:::note -`remove` and `show` do not support S3; they operate on Cloud Pods only. -::: - -### `reset` - -Discard the running AWS emulator's in-memory state (all created resources such as S3 buckets and Lambda functions are dropped). -The emulator **keeps running**; only its state is cleared. - -```bash -lstk reset -lstk reset --force -``` - -| Option | Description | -|:----------|:----------------------------------------------------------------| -| `--force` | Skip the confirmation prompt. Required in non-interactive mode. | - -In interactive mode, `reset` prompts for confirmation before clearing state. -In non-interactive mode it fails unless `--force` is passed: - -```text -reset requires confirmation; use --force to skip in non-interactive mode -``` - -`reset` supports [`--json`](#structured-output): on success the `data` payload reports the reset emulator and `"reset": true`. - -:::note -`reset` clears in-memory state only. -It does **not** wipe the on-disk volume (certificates, persistence data, cached tools). -To clear that, stop the emulator and run [`lstk volume clear`](#volume). -::: - -### `volume` - -Manage the emulator volume: the host directory that holds persistent state such as certificates, downloaded tools, and persistence data. - -```bash -lstk volume path -lstk volume clear [options] -``` - -#### `volume path` - -Prints the resolved volume directory for every emulator in your config, one per line. -With the default config (a single `aws` emulator) it prints one path. -Each path is the container's configured `volume` value, or the default OS cache location if `volume` is unset (`~/Library/Caches/lstk/volume/localstack-aws` on macOS, `~/.cache/lstk/volume/localstack-aws` on Linux). - -```bash -# Print the volume directory for each configured emulator -lstk volume path -``` - -#### `volume clear` - -Removes all data from the emulator volume directory, resetting cached state. -It operates on all configured emulators by default, or a single one with `--type`. -Before clearing, it lists each target as `: ()`. - -| Option | Description | -|:----------------|:-----------------------------------------| -| `--force` | Skip the confirmation prompt | -| `--type ` | Clear only the emulator of this type | - -```bash -# Clear all configured emulator volumes (prompts for confirmation) -lstk volume clear - -# Clear only the AWS emulator volume -lstk volume clear --type aws - -# Skip the confirmation prompt -lstk volume clear --force - -# Clear without prompting in a non-interactive environment -lstk volume clear --type snowflake --force -``` - -In an interactive terminal, `lstk volume clear` prompts `Clear volume data? This cannot be undone` before deleting anything; choosing **NO** or pressing Ctrl+C cancels with no changes. -In non-interactive mode, `--force` is required, otherwise the command fails with `volume clear requires confirmation; use --force to skip in non-interactive mode`. - -:::caution -If the volume contains files owned by `root` (created by Docker), clearing fails with a permission error. -Re-run with elevated privileges: - -```bash -sudo lstk volume clear -``` -::: - -### `login` - -Authenticate with LocalStack via a browser-based device authorization flow and store the resulting credential in your system keyring. -This command requires an interactive terminal. - -```bash -lstk login -``` - -`lstk` opens your default browser to the LocalStack Web Application, shows a one-time code, and waits for you to approve the request. -If the browser cannot open automatically, `lstk` prints the URL to visit manually. -On success it stores the **license token** returned by the platform (not the raw browser bearer token). - -If you are already authenticated — either `LOCALSTACK_AUTH_TOKEN` is set or a token already exists in storage — `login` prints `You're already logged in` and exits without starting a new flow. - -In non-interactive mode (piped output, CI, or `--non-interactive`), `login` fails with `login requires an interactive terminal`. -The `--config ` flag selects which `config.toml` is loaded, which affects `keyring`, `web_app_url`, and `api_endpoint` resolution. - -:::note -If you approve the request in the browser only *after* pressing a key in the terminal, `lstk` reports `auth request not confirmed - please complete the authentication in your browser`. -Re-run `lstk login` and approve in the browser before continuing. -::: - -The credential is written to the system keyring (service `lstk`, key `lstk.auth-token`). -When the keyring is unavailable — or `LSTK_KEYRING=file` is set — `lstk` stores it in a file at `/auth-token` (mode `0600`) instead. - -Endpoints used by the flow can be overridden via config or environment: - -| Config key | Env var | Default | Description | -|:---------------|:--------------------|:-------------------------------|:-----------------------------------------------------------------------------| -| `keyring` | `LSTK_KEYRING` | (system keyring) | Set to `file` to force file-based token storage instead of the OS keyring. | -| `web_app_url` | `LSTK_WEB_APP_URL` | `https://app.localstack.cloud` | Base URL used to build the browser authorization link. | -| `api_endpoint` | `LSTK_API_ENDPOINT` | `https://api.localstack.cloud` | LocalStack platform API endpoint used for the device flow and license token. | - -```bash -# Force file-based token storage during login -LSTK_KEYRING=file lstk login - -# Use a specific config file -lstk --config ./.lstk/config.toml login -``` - -### `logout` - -Remove stored authentication credentials. - -```bash -lstk logout -lstk logout --non-interactive -``` - -`logout` deletes the auth token from your system keyring (falling back to the file-based token at `/auth-token` when the keyring is unavailable or `LSTK_KEYRING=file` is set) and removes the cached license file. -On success it prints `Logged out successfully`. - -The outcome depends on how you are authenticated: - -| Situation | Behavior | -|:----------|:---------| -| A token is stored (from `lstk login`) | The token is deleted from the keyring and file fallback, the cached license is removed, and `lstk` prints `Logged out successfully`. | -| No stored token, but `LOCALSTACK_AUTH_TOKEN` is set | Nothing is deleted. `lstk` prints a note that you are authenticated via the environment variable and to unset it to log out. | -| No stored token and no `LOCALSTACK_AUTH_TOKEN` | `lstk` prints `Not currently logged in` and exits successfully. | - -:::note -`logout` never clears the `LOCALSTACK_AUTH_TOKEN` environment variable, and it does not stop running emulators. -If a LocalStack emulator is still running after logout, `lstk` prints a note reminding you it is running in the background; run `lstk stop` to stop it. -::: - -### `setup` - -Set up CLI integration for an emulator type. -`lstk setup` is a grouping command with no action of its own; the work is done by its subcommands, `setup aws` and `setup azure`. - -```bash -lstk setup aws -lstk setup azure -``` - -#### `setup aws` - -Create or update a `localstack` profile in `~/.aws/config` and `~/.aws/credentials` so the AWS CLI and SDKs can target LocalStack. - -```bash -lstk setup aws -lstk setup aws --force -``` - -| Option | Description | -|:----------|:-----------------------------------------------------------------------------------------| -| `--force` | Overwrite an existing `localstack` profile whose values differ, and skip the confirmation prompt. | - -On an interactive terminal it prompts (Y/n) before making changes. -In non-interactive mode (piped output, CI, or `--non-interactive`) it writes the profile with defaults without prompting and exits `0`; a failed write or check returns a non-zero exit code so automation notices. -Overwriting an existing `localstack` profile whose values differ requires `--force` (which also skips the interactive prompt); creating a fresh profile, completing a partial one, or leaving an already-correct profile in place never needs it. - -It writes the following profile (existing unrelated profiles are preserved): - -```ini -# ~/.aws/config -[profile localstack] -region = us-east-1 -output = json -endpoint_url = http://localhost.localstack.cloud:4566 - -# ~/.aws/credentials -[localstack] -aws_access_key_id = test -aws_secret_access_key = test -``` - -Afterwards, target LocalStack by passing `--profile localstack` or exporting `AWS_PROFILE`: - -```bash -export AWS_PROFILE=localstack -aws s3 ls -``` - -The endpoint host is resolved the same way as for [`lstk aws`](#endpoint-resolution) (probing `localhost.localstack.cloud` and falling back to `127.0.0.1`), and [`LOCALSTACK_HOST`](#environment-variables) overrides the host and port written into the profile. -The port comes from your AWS emulator's configured `port` (default `4566`); if no `aws` emulator is configured, the command fails with `no aws emulator configured`. - -If the `localstack` profile is already configured correctly, `lstk` reports `LocalStack AWS profile is already configured.` and makes no changes. - -On an interactive terminal, `setup aws` prompts (Y/n) before writing. Overwriting an existing `localstack` profile whose values differ requires `--force` (which also skips the prompt); writing a fresh profile, completing a partial one, or leaving an already-correct profile unchanged never needs it. - -:::note -The former `lstk config profile` command has been removed; use `lstk setup aws`. -::: - -#### `setup azure` - -Prepare an isolated Azure CLI configuration directory that routes [`lstk az`](#az) commands to the LocalStack Azure emulator. -Your global `~/.azure` configuration is left untouched. - -```bash -lstk setup azure -# alias: -lstk setup az -``` - -`setup azure` registers a custom Azure cloud (`LocalStack`) whose endpoints point at the LocalStack Azure emulator, activates it, disables Azure CLI instance discovery and telemetry, and performs a one-time dummy service-principal login — all inside a dedicated config directory under the `lstk` config dir (via `AZURE_CONFIG_DIR`). -It requires the `az` CLI to be installed and a running LocalStack Azure emulator. - -To instead redirect your **global** `az` (so existing scripts run unmodified against LocalStack), see [`lstk az start-interception`](#az). - -#### `setup azure` - -Prepare an isolated Azure CLI config directory (under the `lstk` config dir, via `AZURE_CONFIG_DIR`) that routes [`lstk az`](#az) commands to the LocalStack Azure emulator. -It registers a custom Azure cloud (`LocalStack`) pointing at LocalStack's Azure endpoints, activates it, disables Azure CLI instance discovery and telemetry, and performs a one-time dummy service-principal login. -Your global `~/.azure` configuration is left untouched. - -```bash -lstk setup azure -``` - -Requires the `az` CLI on your `PATH` and a running LocalStack Azure emulator. -Run this once; afterwards use `lstk az ` to run Azure CLI commands against LocalStack. - -### `config` - -Manage CLI configuration. -`config` has no behavior of its own; run it with a subcommand. - -#### `config path` - -Print the resolved path to the active `config.toml`. - -```bash -lstk config path -``` - -This subcommand is read-only: it never creates or initializes a config file. -If `--config ` is set, it prints that path verbatim. -Otherwise it prints the already-loaded config path, the first existing config in the search order, or the path where a config would be created on first run. - -### `update` - -Check for and apply updates to the `lstk` CLI itself. -`lstk` auto-detects how it was installed (Homebrew, npm, or direct binary) and updates using that same method. -Development builds (version `dev`) are skipped, and updates are checked against the latest [GitHub release](https://github.com/localstack/lstk/releases/latest). - -```bash -lstk update [options] -``` - -| Option | Description | -|:--------------------|:-------------------------------------------------------------| -| `--check` | Check for updates without installing them | -| `--non-interactive` | Use plain output instead of the TUI (update logic unchanged) | -| `--json` | Emit the result as a JSON envelope (see [Structured output](#structured-output)). With `--check`, `data` reports `currentVersion`/`latestVersion`/`updateAvailable`; after an applied update, `updatedVersion`/`updated`/`method`. | - -Examples: - -```bash -# Check for updates without installing -lstk update --check - -# Update to the latest version -lstk update - -# Update with plain (non-TUI) output -lstk update --non-interactive -``` - -By install method: - -- **Homebrew** (binary under a `Caskroom` path): runs `brew upgrade localstack/tap/lstk`. -- **npm** (binary under `node_modules`): runs `npm install -g @localstack/lstk@latest`. -- **Binary** (anything else): downloads the release asset for your OS/arch from GitHub, extracts it, and replaces the running executable in place. - -With `--check`, `lstk` only reports whether a newer version is available and exits without downloading or installing anything. - -:::note -Set `LSTK_GITHUB_TOKEN` to send an authenticated GitHub request and avoid API rate limits during update checks. -It is optional; updates also work unauthenticated. -::: - -If more than one `lstk` installation is found on your `PATH` (for example a Homebrew binary and an npm one), `lstk update` and the start-time update notification print a warning listing each location, its install method, and which one is currently running, so you can tell which binary an update will actually replace. - -#### Update notification on start - -Separately from `lstk update`, `lstk` checks for a newer version when you run `lstk start` (the default command), using a short timeout that fails silently if GitHub is unreachable. - -In an interactive terminal, when an update is available `lstk` prints the new version and a release-notes link, then prompts: - -```text -Update lstk to latest version? -> Update now [U] - Remind me next time [R] - Skip this version [S] -``` - -- **Update now [U]**: downloads and applies the update, then asks you to re-run your command. -- **Remind me next time [R]**: does nothing; you are reminded on the next run. -- **Skip this version [S]**: records the version in `config.toml` so you are not prompted about it again. - -In non-interactive mode the notification is not a prompt — `lstk` emits a single note (`Update available: → (run lstk update)`) and continues. - -When you choose **Skip this version**, `lstk` writes the skipped version under a `[cli]` table: - -```toml -[cli] -update_skipped_version = "0.5.0" -``` - -While this value matches the latest available version, the start-time update notification for that version is suppressed. -This key is managed automatically and is not intended to be edited by hand. - -### `completion` - -Generate shell completion scripts. - -```bash -lstk completion [bash|zsh|fish|powershell] -``` - -See [Shell completions](#shell-completions) for setup instructions. - -## Global options - -These options are available for all commands: - -| Option | Description | -|:--------------------|:---------------------------------------------------------------------------| -| `--config ` | Path to a specific TOML config file | -| `--non-interactive` | Disable the interactive TUI, use plain output | -| `--json` | Emit a single machine-readable JSON envelope on stdout instead of human-oriented output. Supported by `stop`, `reset`, and `update`; any other command rejects it. See [Structured output](#structured-output). | -| `--persist` | Persist emulator state across restarts (on `start`/bare `lstk` and `restart`) | -| `--type `, `-t ` | Emulator type to start: `aws`, `snowflake`, or `azure` (on `start`/bare `lstk`; records the choice in config). See [Selecting the emulator with `--type`](#selecting-the-emulator-with---type). | -| `--snapshot ` | Snapshot REF to auto-load after start (on `start`/bare `lstk`; overrides config for one run) | -| `--no-snapshot` | Skip auto-loading the configured snapshot (on `start`/bare `lstk`) | -| `--timeout ` | Startup readiness deadline for `start`/bare `lstk`, as a Go duration; overrides `LSTK_STARTUP_TIMEOUT` for one run. See [`start`](#start). | -| `-v`, `--version` | Print the version and exit | -| `-h`, `--help` | Print help and exit | - -## Interactive and non-interactive mode - -`lstk` automatically selects its output mode: - -- **Interactive mode** (TUI): used when both stdin and stdout are connected to a terminal. - Commands like `start`, `stop`, `restart`, `status`, `login`, `update`, and the confirmation prompts of `reset`/`volume clear` display a Bubble Tea-powered terminal UI. -- **Non-interactive mode** (plain text): used when the output is piped, redirected, or running in CI. - Force this in a TTY with `--non-interactive`. - -```bash -# Force plain output even in an interactive terminal -lstk --non-interactive start -``` - -:::note -`lstk login` requires an interactive terminal; if you need to authenticate in CI, set `LOCALSTACK_AUTH_TOKEN` instead. -Commands that mutate state without prompting in CI (`reset`, `volume clear`) require `--force`. -`lstk setup aws` works non-interactively — it writes the profile with defaults and needs `--force` only to overwrite a conflicting `localstack` profile. -::: - -## Structured output - -The global `--json` flag makes a command emit a single, machine-readable JSON object on stdout instead of human-oriented text, for scripting and CI. -JSON support is available per command: `stop`, `reset`, and `update` accept `--json`. -Any other command rejects it with an error envelope (`error.code: NOT_JSON_CAPABLE`) rather than silently printing plain text. - -Every JSON-capable command writes **exactly one** JSON object with the following envelope shape: - -```json -{ - "schemaVersion": 1, - "command": "stop", - "status": "ok", - "data": { - "emulators": [ - { "type": "aws", "name": "localstack-aws", "wasRunning": true } - ] - }, - "warnings": [], - "error": null -} -``` - -| Field | Type | Description | -|:----------------|:----------------|:-----------------------------------------------------------------------------------------------------| -| `schemaVersion` | integer | Wire-format version of the envelope, always `1` for this schema. Check it once before parsing. | -| `command` | string | The command that produced the envelope (e.g. `"stop"`, `"reset"`). | -| `status` | string | `"ok"` or `"error"` — branch on this first. | -| `data` | object or `null`| Command-specific result. Non-null when `status` is `"ok"`, `null` when it is `"error"`. | -| `warnings` | array | Non-fatal notices, always present (empty array when there are none). Each entry is `{ "code", "message" }`. | -| `error` | object or `null`| The machine-readable failure. Non-null when `status` is `"error"`, `null` otherwise. | - -When `status` is `"error"`, the `error` object carries a stable `code` (e.g. `EMULATOR_NOT_RUNNING`, `CONFIRMATION_REQUIRED`, `RUNTIME_UNAVAILABLE`), a coarse `category`, a human-readable `message` (informational only — branch on `code`, not `message`), and a `retryable` boolean: - -```json -{ - "schemaVersion": 1, - "command": "reset", - "status": "error", - "data": null, - "warnings": [], - "error": { - "code": "CONFIRMATION_REQUIRED", - "category": "USAGE", - "message": "reset requires confirmation; use --force to skip in non-interactive mode", - "retryable": false - } -} -``` - -### Exit codes - -For a full enumeration, read `error.code` from the envelope; the process exit code carries only the two most common, mechanically-remediable failures: - -| Exit code | Meaning | -|:----------|:--------------------------------------------------------------------------------------------| -| `0` | `status: "ok"`. | -| `1` | `status: "error"` for any code other than the two below. | -| `2` | A Cobra-level usage error that occurred before `--json` could be recognized (plain-text error on stderr, not an envelope). | -| `3` | `error.code == "CONFIRMATION_REQUIRED"` (re-run with `--force`). | -| `4` | `error.code == "AUTH_REQUIRED"` (run `lstk login` or set `LOCALSTACK_AUTH_TOKEN`). | - -:::note -`--json` implies non-interactive behavior: no TUI and no prompts. -Combining it with a destructive command that would otherwise prompt (`reset`) still requires `--force`, which surfaces as `CONFIRMATION_REQUIRED` (exit code `3`) when omitted. -::: - -## Environment variables - -The following environment variables configure `lstk` itself (not the LocalStack container): - -| Variable | Description | -|:-----------------------------|:-----------------------------------------------------------------------------------------------------------------| -| `LOCALSTACK_AUTH_TOKEN` | Auth token for non-interactive runs or to skip browser login. Used when no keyring token is stored. | -| `LOCALSTACK_HOST` | Override the host (and optional port) used when resolving and printing the emulator endpoint, and when writing the AWS CLI profile. Bypasses the `localhost.localstack.cloud` DNS probe. | -| `LOCALSTACK_DISABLE_EVENTS` | Set to `1` to disable anonymous telemetry event reporting. | -| `DOCKER_HOST` | Override the Docker daemon socket (e.g. `unix:///home/user/.colima/default/docker.sock`). | -| `LSTK_KEYRING` | Set to `file` to force file-based token storage instead of the system keyring. | -| `LSTK_STARTUP_TIMEOUT` | Startup readiness deadline for `lstk start`, as a Go duration (e.g. `90s`, `2m`). Zero/unset uses the per-mode default (20s interactive, 60s non-interactive). See [`start`](#start). | -| `LSTK_MERGE_STRATEGY` | Default merge strategy for `snapshot load` / `load` (`account-region-merge`, `overwrite`, or `service-merge`) when `--merge` is not passed. An explicit `--merge` always wins. | -| `LSTK_OTEL` | Set to `1` to enable OpenTelemetry trace export (disabled by default). See [OpenTelemetry tracing](#opentelemetry-tracing). | -| `LSTK_GITHUB_TOKEN` | Optional GitHub token used when checking for or downloading `lstk` updates (raises GitHub API rate limits). | -| `LSTK_API_ENDPOINT` | Override the LocalStack platform API base URL. Default: `https://api.localstack.cloud`. | -| `LSTK_WEB_APP_URL` | Override the LocalStack Web Application URL used for browser login. Default: `https://app.localstack.cloud`. | - -When `DOCKER_HOST` is not set, `lstk` tries the default Docker socket and then probes common alternatives (Colima at `~/.colima/default/docker.sock` or `~/.config/colima/default/docker.sock`, OrbStack at `~/.orbstack/run/docker.sock`). - -When `LSTK_OTEL` is enabled, the standard `OTEL_EXPORTER_OTLP_*` environment variables are honored by the OpenTelemetry SDK. - -### Container-injected variables - -`lstk` injects several environment variables into the LocalStack container on every start, in addition to any profiles you configure: - -| Variable | Default value | Description | -|:---------------------------|:---------------------------------------------|:---------------------------------------------| -| `LOCALSTACK_AUTH_TOKEN` | (your resolved token) | Passed from the CLI to activate the license. | -| `GATEWAY_LISTEN` | `:4566,:443` | Ports the emulator binds inside the container. | -| `MAIN_CONTAINER_NAME` | `localstack-aws` | Container name for internal references. | -| `LOCALSTACK_HOST` | `localhost.localstack.cloud:` | Hostname/port the emulator advertises. | -| `LOCALSTACK_PERSISTENCE` | `1` (only with `--persist`) | Enables state persistence across restarts. | -| `LOCALSTACK_CLIENT_NAME` | `lstk` | Identifies the client that started the emulator. | -| `LOCALSTACK_CLIENT_VERSION`| (the `lstk` version) | Version of the client that started the emulator. | - -When a Docker socket is detected it is bind-mounted into the container and `DOCKER_HOST=unix:///var/run/docker.sock` is injected so the emulator can spawn its own containers. -`lstk` also forwards host environment variables matching `CI` and `LOCALSTACK_*` (the host `LOCALSTACK_AUTH_TOKEN` is dropped so it cannot override the token resolved by `lstk`). - -The container also gets port mappings for `4566`, `443`, and the service port range `4510-4559`. - -:::note -`GATEWAY_LISTEN` is read from the container's resolved environment (set it via an `[env.*]` profile), not hardcoded. -Beyond controlling which ports the emulator binds, its host part sets the host publish IP for all published ports: a value like `GATEWAY_LISTEN = "0.0.0.0:4566,0.0.0.0:443"` exposes the emulator beyond loopback (e.g. on a remote host), whereas the default binds to `127.0.0.1` only. -::: - -## OpenTelemetry tracing - -`lstk` can export traces of its own command execution over OTLP/HTTP. -Tracing is **disabled by default**. -Enable it with: - -```bash -LSTK_OTEL=1 lstk start -``` - -When enabled, every command is wrapped in a span (e.g. `lstk.start`) recording the exit code and any error. -`lstk` does not hardcode an export target, so the OpenTelemetry Go SDK reads the standard `OTEL_EXPORTER_OTLP_*` environment variables automatically (default target: OTLP/HTTP at `localhost:4318`). -You need an OTLP-compatible backend running to receive the traces. - -## Logging - -`lstk` writes its own diagnostic logs to `lstk.log` in the same directory as the active config file. -This is separate from the LocalStack container logs (which you view with `lstk logs`). - -- The log file is created automatically and appended to across runs. -- When the file exceeds **1 MB**, it is cleared on the next run. -- Use `lstk config path` to find the config directory; `lstk.log` sits alongside `config.toml`. - -## Offline and enterprise environments - -There is no `--offline` flag. Instead, `lstk` degrades gracefully when common enterprise blockers (Docker Hub unreachable, a proxy/TLS interceptor, or an unreachable license server) prevent an internet request: - -- **Image pull**: if the image pull fails but the image is already present locally, `lstk` warns and uses the local image instead of failing. In interactive mode you can also press Esc to abort an in-progress pull and fall back to the local image. -- **License pre-flight**: when the pinned image is already present locally, `lstk` skips its pre-flight license check so a fully offline start is not blocked; the emulator validates the license itself once it starts. When a check does run, a transport-level failure (offline, proxy, or certificate error) is treated as non-fatal and the emulator validates the license instead. A definitive server rejection (HTTP 400/401/403) is handled differently: `lstk` drops the cached license and, in an interactive terminal, offers to log in again and retries the start once with the refreshed credentials (a rejected token often just predates a license purchase or plan change); in non-interactive mode it fails with an error pointing at `lstk logout && lstk login` or a valid `LOCALSTACK_AUTH_TOKEN`. The pre-flight is also skipped — with a warning — when the license server does not recognize the image *tag format* (for example a `dev` nightly or a custom internal-mirror tag): that is not a verdict on the license, so `lstk` defers to the emulator's own startup check rather than blocking the start. -- **Telemetry and update checks** are best-effort and fail silently when offline. - -Pair this behavior with a custom [`image`](#custom-container-image) that points at an internal-registry mirror or a locally loaded image to run `lstk` in an air-gapped environment. - -## Shell completions - -`lstk` includes completion scripts for bash, zsh, fish, and powershell. -If you installed via Homebrew, completions are set up automatically. - -For manual setup: - - - - -```bash -# Load in current session -eval "$(lstk completion bash)" - -# Persist (Linux) -lstk completion bash > /etc/bash_completion.d/lstk - -# Persist (macOS with Homebrew) -lstk completion bash > $(brew --prefix)/etc/bash_completion.d/lstk -``` - -:::note -Use `eval "$(lstk completion bash)"` rather than `source <(lstk completion bash)`. -The `lstk` script works with or without the `bash-completion` package (it bundles a fallback for stock macOS bash 3.2), but `source <(...)` is a silent no-op on that shell. -::: - - - - -```bash -# Load in current session -source <(lstk completion zsh) - -# Persist (Linux) -lstk completion zsh > "${fpath[1]}/_lstk" - -# Persist (macOS with Homebrew) -lstk completion zsh > $(brew --prefix)/share/zsh/site-functions/_lstk -``` - - - - -```bash -# Load in current session -lstk completion fish | source - -# Persist -lstk completion fish > ~/.config/fish/completions/lstk.fish -``` - - - - -Restart your shell after persisting completions. - -## FAQ - -### Can I use `lstk` with Docker Compose? - -No. `lstk` manages its own Docker container directly. -If you use a `docker-compose.yml` to run LocalStack, you do not need `lstk`, and vice versa. -Do not mix `lstk start` with a Docker Compose setup; they are separate, independent methods. - -For Docker Compose configuration, see the [Docker Compose installation guide](/aws/getting-started/installation/#docker-compose). - -### Which Docker image does `lstk` use? - -It depends on the emulator type configured in your `config.toml`. -The AWS emulator uses `localstack/localstack-pro`, the Snowflake emulator uses `localstack/snowflake`, and the Azure emulator uses `localstack/localstack-azure`. -All require a valid auth token (including the free Hobby tier). -See [Emulator types](#emulator-types). - -### How do I pass configuration options like `DEBUG` or `PERSISTENCE` to the container? - -Use environment profiles in your `config.toml`. -Define the variables under an `[env.]` section and reference that name in the `env` list of your container config. -See [Passing environment variables to the container](#passing-environment-variables-to-the-container) for details. - -### How do I save and restore emulator state? - -Use [`lstk snapshot save`](#snapshot) to capture the running AWS emulator's state to a local file or a Cloud Pod, and [`lstk snapshot load`](#snapshot) (or the `lstk save` / `lstk load` aliases) to restore it. -To drop in-memory state without writing a snapshot, use [`lstk reset`](#reset). - -### How do I pin a specific LocalStack version? - -Set the `tag` field in your `config.toml` to a specific version tag: - -```toml -[[containers]] -type = "aws" -tag = "2026.4" -port = "4566" -``` - -## Troubleshooting - -### Port 443 already in use - -By default, LocalStack binds to both port `4566` and port `443` inside the container (controlled by the `GATEWAY_LISTEN` variable). -On some systems, particularly Windows with Hyper-V, IIS, or VPN software, port 443 may already be in use. - -**Symptoms:** - -```text -failed to start LocalStack: Error response from daemon: ports are not available: -exposing port TCP 127.0.0.1:443 -> 127.0.0.1:0: listen tcp4 127.0.0.1:443: bind: -address already in use -``` - -**Fix:** Override `GATEWAY_LISTEN` to bind only to port 4566: - -```toml -[[containers]] -type = "aws" -tag = "latest" -port = "4566" -env = ["nossl"] - -[env.nossl] -GATEWAY_LISTEN = "0.0.0.0:4566" -``` - -This tells the container to skip the port 443 binding entirely. - -### Docker is not running - -`lstk` requires a running Docker daemon. -If Docker is not reachable, you will see an error like: - -```text -Error: runtime not healthy -``` - -**Fix:** Start Docker Desktop (macOS/Windows) or the Docker daemon (`sudo systemctl start docker` on Linux). -If you use Colima or OrbStack, make sure the VM is running. -You can also point `lstk` at a custom socket with `DOCKER_HOST`. - -### Authentication required in non-interactive mode - -When running without a TTY (e.g. in CI), `lstk` cannot open a browser for login. -If no token is found in the keyring or environment, it fails: - -```text -authentication required: set LOCALSTACK_AUTH_TOKEN or run in interactive mode -``` - -**Fix:** Set the `LOCALSTACK_AUTH_TOKEN` environment variable before running `lstk`: - -```bash -export LOCALSTACK_AUTH_TOKEN= -lstk --non-interactive start -``` - -You can find your auth token on the [Auth Tokens page](https://app.localstack.cloud/workspace/auth-tokens). - -### License validation failed - -If your auth token is invalid, expired, or not linked to an active license, the LocalStack container exits with a license error: - -```text -The license activation failed for the following reason: -No credentials were found in the environment. -``` - -**Fix:** - -- Verify your token is valid at the [Auth Tokens page](https://app.localstack.cloud/workspace/auth-tokens). -- Make sure the token is set correctly, either via `lstk login` or the `LOCALSTACK_AUTH_TOKEN` environment variable. -- A stale token or cached license no longer requires a manual `lstk logout`: when the platform definitively rejects it, `lstk` drops the cached license and, in an interactive terminal, prompts you to log in again and retries automatically. In non-interactive mode, run `lstk logout && lstk login` (or set a valid `LOCALSTACK_AUTH_TOKEN`) and re-run. - -### Image pull failed - -If `lstk` cannot pull the Docker image, check your network connection and Docker configuration. -On corporate networks, you may need to configure Docker's proxy settings, see [How do I configure LocalStack to use my corporate HTTP and HTTPS proxy?](/aws/getting-started/faq/#how-do-i-configure-localstack-to-use-my-corporate-http-and-https-proxy). - -### Unknown environment profile - -If your container config references an `env` profile that doesn't exist, `lstk` returns: - -```text -environment "myprofile" referenced in container config not found -``` - -**Fix:** Make sure the profile name in the `env` list matches an `[env.]` section in your `config.toml`: - -```toml -[[containers]] -type = "aws" -env = ["myprofile"] # must match the section name below - -[env.myprofile] -DEBUG = "1" -``` - -### Getting help - -If the steps above don't resolve your issue, see [Get Help](/aws/help-support/get-help/) for the available support channels, including the support email and in-app chat. diff --git a/src/content/docs/aws/developer-tools/running-localstack/lstk/authentication.md b/src/content/docs/aws/developer-tools/running-localstack/lstk/authentication.md new file mode 100644 index 00000000..1b33f526 --- /dev/null +++ b/src/content/docs/aws/developer-tools/running-localstack/lstk/authentication.md @@ -0,0 +1,114 @@ +--- +title: lstk Authentication +description: How lstk resolves your auth token, and the login and logout commands. +template: doc +tags: ['Hobby'] +--- + +`lstk` resolves your auth token in the following order: + +1. **System keyring**: a token stored by a previous `lstk login`. +2. **`LOCALSTACK_AUTH_TOKEN` environment variable**: used only when the keyring has no token. +3. **Browser login**: triggered automatically in interactive mode when neither of the above provides a token. + +:::caution +The keyring token takes precedence over `LOCALSTACK_AUTH_TOKEN`. +If you set or change the environment variable but a keyring token already exists, the environment variable is ignored. +Run `lstk logout` to clear the stored keyring token first. +::: + +## Logging in + +```bash +lstk login +``` + +Opens a browser window for authentication and stores the resulting token in your system keyring. +This command requires an interactive terminal. +See the [`login`](#login) command below for the full flow and the endpoints it uses. + +## Logging out + +```bash +lstk logout +``` + +Removes the stored credentials from the system keyring and the file-based fallback, and clears the cached license. +`logout` cannot clear a token supplied via `LOCALSTACK_AUTH_TOKEN`; if you authenticated that way, unset the variable instead. +See the [`logout`](#logout) command below for the full behavior. + +## File-based token storage + +On systems where the system keyring is unavailable, `lstk` automatically falls back to storing the token in a file (`/auth-token`, mode `0600`). +You can force file-based storage by setting: + +```bash +export LSTK_KEYRING=file +``` + +## `login` + +Authenticate with LocalStack via a browser-based device authorization flow and store the resulting credential in your system keyring. +This command requires an interactive terminal. + +```bash +lstk login +``` + +`lstk` opens your default browser to the LocalStack Web Application, shows a one-time code, and waits for you to approve the request. +If the browser cannot open automatically, `lstk` prints the URL to visit manually. +On success it stores the **license token** returned by the platform (not the raw browser bearer token). + +If you are already authenticated — either `LOCALSTACK_AUTH_TOKEN` is set or a token already exists in storage — `login` prints `You're already logged in` and exits without starting a new flow. + +In non-interactive mode (piped output, CI, or `--non-interactive`), `login` fails with `login requires an interactive terminal`. +The `--config ` flag selects which `config.toml` is loaded, which affects `keyring`, `web_app_url`, and `api_endpoint` resolution. + +:::note +If you approve the request in the browser only *after* pressing a key in the terminal, `lstk` reports `auth request not confirmed - please complete the authentication in your browser`. +Re-run `lstk login` and approve in the browser before continuing. +::: + +The credential is written to the system keyring (service `lstk`, key `lstk.auth-token`). +When the keyring is unavailable — or `LSTK_KEYRING=file` is set — `lstk` stores it in a file at `/auth-token` (mode `0600`) instead. + +Endpoints used by the flow can be overridden via config or environment: + +| Config key | Env var | Default | Description | +|:---------------|:--------------------|:-------------------------------|:-----------------------------------------------------------------------------| +| `keyring` | `LSTK_KEYRING` | (system keyring) | Set to `file` to force file-based token storage instead of the OS keyring. | +| `web_app_url` | `LSTK_WEB_APP_URL` | `https://app.localstack.cloud` | Base URL used to build the browser authorization link. | +| `api_endpoint` | `LSTK_API_ENDPOINT` | `https://api.localstack.cloud` | LocalStack platform API endpoint used for the device flow and license token. | + +```bash +# Force file-based token storage during login +LSTK_KEYRING=file lstk login + +# Use a specific config file +lstk --config ./.lstk/config.toml login +``` + +## `logout` + +Remove stored authentication credentials. + +```bash +lstk logout +lstk logout --non-interactive +``` + +`logout` deletes the auth token from your system keyring (falling back to the file-based token at `/auth-token` when the keyring is unavailable or `LSTK_KEYRING=file` is set) and removes the cached license file. +On success it prints `Logged out successfully`. + +The outcome depends on how you are authenticated: + +| Situation | Behavior | +|:----------|:---------| +| A token is stored (from `lstk login`) | The token is deleted from the keyring and file fallback, the cached license is removed, and `lstk` prints `Logged out successfully`. | +| No stored token, but `LOCALSTACK_AUTH_TOKEN` is set | Nothing is deleted. `lstk` prints a note that you are authenticated via the environment variable and to unset it to log out. | +| No stored token and no `LOCALSTACK_AUTH_TOKEN` | `lstk` prints `Not currently logged in` and exits successfully. | + +:::note +`logout` never clears the `LOCALSTACK_AUTH_TOKEN` environment variable, and it does not stop running emulators. +If a LocalStack emulator is still running after logout, `lstk` prints a note reminding you it is running in the background; run `lstk stop` to stop it. +::: diff --git a/src/content/docs/aws/developer-tools/running-localstack/lstk/automation.mdx b/src/content/docs/aws/developer-tools/running-localstack/lstk/automation.mdx new file mode 100644 index 00000000..1e52313f --- /dev/null +++ b/src/content/docs/aws/developer-tools/running-localstack/lstk/automation.mdx @@ -0,0 +1,179 @@ +--- +title: lstk Automation & CI +description: Global options, non-interactive mode, structured JSON output, environment variables, tracing, and logging for scripting lstk. +template: doc +tags: ['Hobby'] +--- + +## Global options + +These options are available for all commands: + +| Option | Description | +|:--------------------|:------------------------------------------------------------------------------| +| `--config ` | Path to a specific TOML config file | +| `--non-interactive` | Disable the interactive TUI, use plain output | +| `--json` | Emit a single machine-readable JSON envelope on stdout instead of human-oriented output. Supported by `stop`, `reset`, and `update`; any other command rejects it. See [Structured output](#structured-output). | +| `--persist` | Persist emulator state across restarts (on `start`/bare `lstk` and `restart`) | +| `--type `, `-t ` | Emulator type to start: `aws`, `snowflake`, or `azure` (on `start`/bare `lstk`; records the choice in config). See [Selecting the emulator with `--type`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#selecting-the-emulator-with---type). | +| `--snapshot ` | Snapshot REF to auto-load after start (on `start`/bare `lstk`; overrides config for one run) | +| `--no-snapshot` | Skip auto-loading the configured snapshot (on `start`/bare `lstk`) | +| `--timeout ` | Startup readiness deadline for `start`/bare `lstk`, as a Go duration; overrides `LSTK_STARTUP_TIMEOUT` for one run. See [`start`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#start). | +| `-v`, `--version` | Print the version and exit | +| `-h`, `--help` | Print help and exit | + +## Interactive and non-interactive mode + +`lstk` automatically selects its output mode: + +- **Interactive mode** (TUI): used when both stdin and stdout are connected to a terminal. + Commands like `start`, `stop`, `restart`, `status`, `login`, `update`, and the confirmation prompts of `reset`/`volume clear` display a Bubble Tea-powered terminal UI. +- **Non-interactive mode** (plain text): used when the output is piped, redirected, or running in CI. + Force this in a TTY with `--non-interactive`. + +```bash +# Force plain output even in an interactive terminal +lstk --non-interactive start +``` + +:::note +`lstk login` requires an interactive terminal; if you need to authenticate in CI, set `LOCALSTACK_AUTH_TOKEN` instead. +Commands that mutate state without prompting in CI (`reset`, `volume clear`) require `--force`. +`lstk setup aws` works non-interactively — it writes the profile with defaults and needs `--force` only to overwrite a conflicting `localstack` profile. +::: + +## Structured output + +The global `--json` flag makes a command emit a single, machine-readable JSON object on stdout instead of human-oriented text, for scripting and CI. +JSON support is available per command: `stop`, `reset`, and `update` accept `--json`. +Any other command rejects it with an error envelope (`error.code: NOT_JSON_CAPABLE`) rather than silently printing plain text. + +Every JSON-capable command writes **exactly one** JSON object with the following envelope shape: + +```json +{ + "schemaVersion": 1, + "command": "stop", + "status": "ok", + "data": { + "emulators": [ + { "type": "aws", "name": "localstack-aws", "wasRunning": true } + ] + }, + "warnings": [], + "error": null +} +``` + +| Field | Type | Description | +|:----------------|:-----------------|:--------------------------------------------------------------------------------------------------------| +| `schemaVersion` | integer | Wire-format version of the envelope, always `1` for this schema. Check it once before parsing. | +| `command` | string | The command that produced the envelope (e.g. `"stop"`, `"reset"`). | +| `status` | string | `"ok"` or `"error"` — branch on this first. | +| `data` | object or `null`| Command-specific result. Non-null when `status` is `"ok"`, `null` when it is `"error"`. | +| `warnings` | array | Non-fatal notices, always present (empty array when there are none). Each entry is `{ "code", "message" }`. | +| `error` | object or `null`| The machine-readable failure. Non-null when `status` is `"error"`, `null` otherwise. | + +When `status` is `"error"`, the `error` object carries a stable `code` (e.g. `EMULATOR_NOT_RUNNING`, `CONFIRMATION_REQUIRED`, `RUNTIME_UNAVAILABLE`), a coarse `category`, a human-readable `message` (informational only — branch on `code`, not `message`), and a `retryable` boolean: + +```json +{ + "schemaVersion": 1, + "command": "reset", + "status": "error", + "data": null, + "warnings": [], + "error": { + "code": "CONFIRMATION_REQUIRED", + "category": "USAGE", + "message": "reset requires confirmation; use --force to skip in non-interactive mode", + "retryable": false + } +} +``` + +### Exit codes + +For a full enumeration, read `error.code` from the envelope; the process exit code carries only the two most common, mechanically-remediable failures: + +| Exit code | Meaning | +|:----------|:-------------------------------------------------------------------------------------------| +| `0` | `status: "ok"`. | +| `1` | `status: "error"` for any code other than the two below. | +| `2` | A Cobra-level usage error that occurred before `--json` could be recognized (plain-text error on stderr, not an envelope). | +| `3` | `error.code == "CONFIRMATION_REQUIRED"` (re-run with `--force`). | +| `4` | `error.code == "AUTH_REQUIRED"` (run `lstk login` or set `LOCALSTACK_AUTH_TOKEN`). | + +:::note +`--json` implies non-interactive behavior: no TUI and no prompts. +Combining it with a destructive command that would otherwise prompt (`reset`) still requires `--force`, which surfaces as `CONFIRMATION_REQUIRED` (exit code `3`) when omitted. +::: + +## Environment variables + +The following environment variables configure `lstk` itself (not the LocalStack container): + +| Variable | Description | +|:-------------------------------|:---------------------------------------------------------------------------------------------------------------------| +| `LOCALSTACK_AUTH_TOKEN` | Auth token for non-interactive runs or to skip browser login. Used when no keyring token is stored. | +| `LOCALSTACK_HOST` | Override the host (and optional port) used when resolving and printing the emulator endpoint, and when writing the AWS CLI profile. Bypasses the `localhost.localstack.cloud` DNS probe. | +| `LOCALSTACK_DISABLE_EVENTS` | Set to `1` to disable anonymous telemetry event reporting. | +| `DOCKER_HOST` | Override the Docker daemon socket (e.g. `unix:///home/user/.colima/default/docker.sock`). | +| `LSTK_KEYRING` | Set to `file` to force file-based token storage instead of the system keyring. | +| `LSTK_STARTUP_TIMEOUT` | Startup readiness deadline for `lstk start`, as a Go duration (e.g. `90s`, `2m`). Zero/unset uses the per-mode default (20s interactive, 60s non-interactive). See [`start`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#start). | +| `LSTK_MERGE_STRATEGY` | Default merge strategy for `snapshot load` / `load` (`account-region-merge`, `overwrite`, or `service-merge`) when `--merge` is not passed. An explicit `--merge` always wins. | +| `LSTK_OTEL` | Set to `1` to enable OpenTelemetry trace export (disabled by default). See [OpenTelemetry tracing](#opentelemetry-tracing). | +| `LSTK_GITHUB_TOKEN` | Optional GitHub token used when checking for or downloading `lstk` updates (raises GitHub API rate limits). | +| `LSTK_API_ENDPOINT` | Override the LocalStack platform API base URL. Default: `https://api.localstack.cloud`. | +| `LSTK_WEB_APP_URL` | Override the LocalStack Web Application URL used for browser login. Default: `https://app.localstack.cloud`. | + +When `DOCKER_HOST` is not set, `lstk` tries the default Docker socket and then probes common alternatives (Colima at `~/.colima/default/docker.sock` or `~/.config/colima/default/docker.sock`, OrbStack at `~/.orbstack/run/docker.sock`). + +When `LSTK_OTEL` is enabled, the standard `OTEL_EXPORTER_OTLP_*` environment variables are honored by the OpenTelemetry SDK. + +### Container-injected variables + +`lstk` injects several environment variables into the LocalStack container on every start, in addition to any profiles you configure: + +| Variable | Default value | Description | +|:-----------------------------|:-------------------------------------------------|:---------------------------------------------| +| `LOCALSTACK_AUTH_TOKEN` | (your resolved token) | Passed from the CLI to activate the license. | +| `GATEWAY_LISTEN` | `:4566,:443` | Ports the emulator binds inside the container. | +| `MAIN_CONTAINER_NAME` | `localstack-aws` | Container name for internal references. | +| `LOCALSTACK_HOST` | `localhost.localstack.cloud:` | Hostname/port the emulator advertises. | +| `LOCALSTACK_PERSISTENCE` | `1` (only with `--persist`) | Enables state persistence across restarts. | +| `LOCALSTACK_CLIENT_NAME` | `lstk` | Identifies the client that started the emulator. | +| `LOCALSTACK_CLIENT_VERSION`| (the `lstk` version) | Version of the client that started the emulator. | + +When a Docker socket is detected it is bind-mounted into the container and `DOCKER_HOST=unix:///var/run/docker.sock` is injected so the emulator can spawn its own containers. +`lstk` also forwards host environment variables matching `CI` and `LOCALSTACK_*` (the host `LOCALSTACK_AUTH_TOKEN` is dropped so it cannot override the token resolved by `lstk`). + +The container also gets port mappings for `4566`, `443`, and the service port range `4510-4559`. + +:::note +`GATEWAY_LISTEN` is read from the container's resolved environment (set it via an `[env.*]` profile), not hardcoded. +Beyond controlling which ports the emulator binds, its host part sets the host publish IP for all published ports: a value like `GATEWAY_LISTEN = "0.0.0.0:4566,0.0.0.0:443"` exposes the emulator beyond loopback (e.g. on a remote host), whereas the default binds to `127.0.0.1` only. +::: + +## OpenTelemetry tracing + +`lstk` can export traces of its own command execution over OTLP/HTTP. +Tracing is **disabled by default**. +Enable it with: + +```bash +LSTK_OTEL=1 lstk start +``` + +When enabled, every command is wrapped in a span (e.g. `lstk.start`) recording the exit code and any error. +`lstk` does not hardcode an export target, so the OpenTelemetry Go SDK reads the standard `OTEL_EXPORTER_OTLP_*` environment variables automatically (default target: OTLP/HTTP at `localhost:4318`). +You need an OTLP-compatible backend running to receive the traces. + +## Logging + +`lstk` writes its own diagnostic logs to `lstk.log` in the same directory as the active config file. +This is separate from the LocalStack container logs (which you view with [`lstk logs`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#logs)). + +- The log file is created automatically and appended to across runs. +- When the file exceeds **1 MB**, it is cleared on the next run. +- Use `lstk config path` to find the config directory; `lstk.log` sits alongside `config.toml`. diff --git a/src/content/docs/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands.md b/src/content/docs/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands.md new file mode 100644 index 00000000..dbd04114 --- /dev/null +++ b/src/content/docs/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands.md @@ -0,0 +1,155 @@ +--- +title: lstk AWS & IaC Commands +description: The aws, az, terraform, cdk, and sam commands that proxy developer tools against LocalStack. +template: doc +tags: ['Hobby'] +--- + +`lstk` proxies developer tools so they run directly against LocalStack. + +:::note +Like `lstk aws`, the `az`, `terraform`, `cdk`, and `sam` proxies do not start the emulator — start it first with [`lstk start`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#start). +Each requires the corresponding third-party CLI to be installed and on your `PATH`. +::: + +:::note +When you interrupt a proxied tool (for example Ctrl+C or `kill` during `lstk terraform apply`), `lstk` forwards the termination signal to the wrapped tool and waits for it to shut down cleanly rather than killing it outright, so operations like releasing a Terraform state lock can complete. The wrapped tool's real exit code is passed through unchanged. +::: + +## `aws` + +Run AWS CLI commands against the running LocalStack emulator. +`lstk aws` proxies your host `aws` CLI with the endpoint, credentials, and region pre-configured, so you don't have to pass `--endpoint-url` or set test credentials yourself. + +```bash +lstk aws s3 ls +lstk aws sqs list-queues +lstk aws s3 mb s3://my-bucket +``` + +It is equivalent to running: + +```bash +aws --endpoint-url http://localhost:4566 +``` + +with `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_DEFAULT_REGION` set automatically. + +Everything after `lstk aws` is forwarded verbatim to the host `aws` binary, including AWS CLI flags such as `--region` or `--output`. +The exit code and `stdout`/`stderr` of the underlying `aws` process are passed through unchanged, so piping and interactive subcommands work as expected. + +| Option | Description | +|:--------------------|:--------------------------------------------------------------------------------------------------| +| `--non-interactive` | Suppress the loading spinner. Unlike other commands, this flag is stripped before invoking `aws` (not forwarded). | + +:::note +`lstk aws` does not start the emulator. +The AWS emulator must already be running (`lstk start`), Docker must be healthy, and the host `aws` CLI must be installed and on your `PATH`. +::: + +### Credentials and region + +`lstk aws` injects credentials in one of two ways: + +- **Profile mode**: if a complete `localstack` profile exists in both `~/.aws/config` and `~/.aws/credentials`, `lstk` appends `--profile localstack` and lets `aws` read the region, credentials, and endpoint from that profile. +- **Profile-less mode**: if the profile is not present, `lstk` runs `aws` with `AWS_ACCESS_KEY_ID=test`, `AWS_SECRET_ACCESS_KEY=test`, and `AWS_DEFAULT_REGION=us-east-1` injected only when those variables are not already set in your environment. In this mode it also prints an informational note: `No AWS profile found, run 'lstk setup aws'`. + +Run [`lstk setup aws`](/aws/developer-tools/running-localstack/lstk/setup-and-maintenance/#setup-aws) to create the `localstack` profile for use with the AWS CLI and SDKs. + +### Endpoint resolution + +By default, `lstk` probes whether `localhost.localstack.cloud` resolves to `127.0.0.1` and uses `localhost.localstack.cloud:` if so, otherwise it falls back to `127.0.0.1:`. +Set [`LOCALSTACK_HOST`](/aws/developer-tools/running-localstack/lstk/automation/#environment-variables) to override the host:port used to reach LocalStack and skip the DNS probe. +The port comes from the AWS container's `port` in `config.toml` (default `4566`). + +## `az` + +Run Azure CLI commands against the running LocalStack Azure emulator. +`lstk az` runs `az` with an isolated `AZURE_CONFIG_DIR` in which a custom Azure cloud is registered against LocalStack's endpoints, so your global `~/.azure` configuration is left untouched and plain `az` keeps talking to real Azure. + +Run [`lstk setup azure`](/aws/developer-tools/running-localstack/lstk/setup-and-maintenance/#setup-azure) once before using this mode. +Everything after `lstk az` is forwarded verbatim to the host `az` binary, and its exit code and output are passed through unchanged. + +```bash +lstk az group list +lstk az storage account list +``` + +The Azure CLI has no `--endpoint-url`/`--profile` equivalent, so the isolation relies entirely on the dedicated config directory prepared by `setup azure`. + +### Global interception (optional) + +If a script must invoke plain `az` (not `lstk az`), you can redirect your **global** `~/.azure` to LocalStack instead: + +```bash +# Point global 'az' at the LocalStack Azure emulator +lstk az start-interception + +# Switch back to real Azure +lstk az stop-interception +``` + +`start-interception` registers and activates the `LocalStack` cloud in your global Azure configuration so every `az` invocation targets LocalStack until you stop it. +`stop-interception` switches the active cloud back to `AzureCloud` (override with `--cloud `) and re-enables instance discovery, but only when `LocalStack` is still the active cloud, to avoid clobbering an unrelated selection. + +:::caution +Interception changes global state that affects every `az` command in any terminal. +Use the isolated `lstk az ` mode unless you specifically need plain `az` to target LocalStack. +::: + +## `terraform` + +Run Terraform against LocalStack, using LocalStack endpoints as AWS provider overrides. +`lstk terraform` (alias `lstk tf`) generates a provider-override file and forwards your arguments to the real `terraform` binary. + +:::note +`lstk terraform` targets the AWS emulator. +To use Terraform with the other emulators, see the relevant emulator docs. +::: + +```bash +lstk terraform init +lstk terraform --region us-west-2 plan +lstk tf apply +``` + +lstk-specific flags must appear **before** the Terraform action: + +| Option | Default | Description | +|:------------------|:---------------------|:---------------------------------------| +| `--region ` | `us-east-1` | Deployment region. | +| `--account ` | `test` | Target AWS account id (12 digits). | + +Relevant environment variables: `AWS_ENDPOINT_URL` (override the auto-resolved endpoint), `LSTK_TF_CMD` (binary to invoke, e.g. `tofu`; default `terraform`), `LSTK_TF_OVERRIDE_FILE_NAME` (override file name; default `localstack_providers_override.tf`), `LSTK_TF_DRY_RUN` (generate the override file but do not run Terraform), `AWS_REGION` (fallback for `--region`), and `AWS_ACCESS_KEY_ID` (fallback for `--account`). + +## `cdk` + +Run the AWS CDK against LocalStack. +Requires the AWS CDK CLI version `2.177.0` or newer on your `PATH`. + +```bash +lstk cdk bootstrap +lstk cdk --region us-west-2 deploy +lstk cdk synth +``` + +The only lstk-specific flag (before the CDK action) is `--region ` (default `us-east-1`); CDK always targets the default LocalStack account `000000000000`, so there is no `--account` flag. +Relevant environment variables: `AWS_ENDPOINT_URL`, `AWS_ENDPOINT_URL_S3`, `LSTK_CDK_CMD` (default `cdk`), and `AWS_REGION`. + +## `sam` + +Run the AWS SAM CLI against LocalStack. +Requires the AWS SAM CLI version `1.95.0` or newer on your `PATH` (older versions ignore `AWS_ENDPOINT_URL` and would target real AWS). + +```bash +lstk sam build +lstk sam --region us-west-2 deploy +lstk sam validate +``` + +lstk-specific flags (before the SAM action): `--region ` (default `us-east-1`) and `--account ` (12 digits, default `000000000000`). +Relevant environment variables: `AWS_ENDPOINT_URL`, `AWS_ENDPOINT_URL_S3`, `LSTK_SAM_CMD` (default `sam`), `AWS_REGION` (fallback for `--region`), and `AWS_ACCESS_KEY_ID` (fallback for `--account`). + +:::note +Compared with `samlocal`, image/container-based Lambda (ECR) deploys and nested CloudFormation stacks are not supported; use `samlocal` for those workflows. +::: diff --git a/src/content/docs/aws/developer-tools/running-localstack/lstk/configuration.mdx b/src/content/docs/aws/developer-tools/running-localstack/lstk/configuration.mdx new file mode 100644 index 00000000..9c4ea895 --- /dev/null +++ b/src/content/docs/aws/developer-tools/running-localstack/lstk/configuration.mdx @@ -0,0 +1,189 @@ +--- +title: lstk Configuration +description: The lstk config.toml file, emulator types, environment variables, custom images, and volume mounts. +template: doc +tags: ['Hobby'] +--- + +`lstk` uses a TOML configuration file, created automatically on first run. + +## Config file search order + +`lstk` uses the first `config.toml` it finds in this order: + +1. `./.lstk/config.toml`: project-local config in the current directory. +2. `$HOME/.config/lstk/config.toml`: user config (created here if `$HOME/.config/` exists). +3. OS default: + - **macOS**: `$HOME/Library/Application Support/lstk/config.toml` + - **Windows**: `%AppData%\lstk\config.toml` + - **Linux**: `$XDG_CONFIG_HOME/lstk/config.toml` or `$HOME/.config/lstk/config.toml` + +On first run, the config is created at path #2 if `$HOME/.config/` already exists; otherwise at the OS default (#3). + +To see the active config file path: + +```bash +lstk config path +``` + +To use a specific config file: + +```bash +lstk --config /path/to/config.toml start +``` + +## Default configuration + +The default `config.toml` created on first run: + +```toml +[[containers]] +type = "aws" # Emulator type. Supported: "aws", "snowflake", "azure" +tag = "latest" # Docker image tag, e.g. "latest", "2026.4" +port = "4566" # Host port the emulator will be accessible on +# image = "" # Full image override (e.g. an internal mirror or offline image) +# volume = "" # Host directory for persistent state (default: OS cache dir) +# volumes = [] # Docker-style "host:container[:ro]" bind mounts (see Volumes) +# env = [] # Named environment profiles to apply (see [env.*] sections below) +# snapshot = "" # Snapshot REF to auto-load after start (AWS only) +``` + +## Config field reference + +| Field | Type | Default | Description | +|:-----------|:---------|:-----------|:-----------------------------------------------------------------------------------------------------| +| `type` | string | `"aws"` | Emulator type. One of `"aws"`, `"snowflake"`, `"azure"`. Run a single `[[containers]]` block at a time. See [Emulator types](#emulator-types). | +| `tag` | string | `"latest"` | Docker image tag (`"latest"`, `"2026.4"`, etc.). Useful for pinning a specific version. Zero-padded months (`"2026.04"`) are normalized to `"2026.4"`. | +| `port` | string | `"4566"` | Host port the emulator listens on (1–65535). The in-container port is always `4566`. | +| `image` | string | (default) | Full image reference that overrides the default Docker Hub image, e.g. an internal-registry mirror or a locally loaded offline image. If it already carries a tag, `tag` is ignored; otherwise `tag` (or `latest`) is appended. | +| `volume` | string | (OS cache) | Host directory for persistent emulator state. Defaults to `/lstk/volume/`. See also `volumes`. | +| `volumes` | string[] | `[]` | Docker-style `"host:container[:ro]"` bind mounts (e.g. init hooks). May also carry the persistence mount (target `/var/lib/localstack`). See [Volume mounts](#volume-mounts). | +| `env` | string[] | `[]` | List of named environment profiles to inject into the container (see below). | +| `snapshot` | string | `""` | Snapshot REF (e.g. `pod:my-baseline` or a local path) to auto-load after the emulator starts. AWS emulator only. See [Auto-loading a snapshot on start](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#auto-loading-a-snapshot-on-start). | + +:::note +There is no `update_prompt` config key. +`lstk` always checks for available updates on startup. +Once you choose to skip a version, `lstk` records it under the `[cli]` table as `update_skipped_version` and stops prompting for that version. +This value is written automatically and is not meant to be hand-edited (see [`update`](/aws/developer-tools/running-localstack/lstk/setup-and-maintenance/#update)). +::: + +## Emulator types + +`lstk` can run more than one kind of emulator. +The `type` field in your `config.toml` selects which one: + +| Type | Docker image | Description | +|:------------|:------------------------------|:-------------------------------------| +| `aws` | `localstack/localstack-pro` | LocalStack AWS emulator (default). | +| `snowflake` | `localstack/snowflake` | LocalStack Snowflake emulator. | +| `azure` | `localstack/localstack-azure` | LocalStack Azure emulator. | + +On the first interactive run, `lstk` prompts you to pick an emulator (`a` for AWS, `s` for Snowflake, `z` for Azure) and writes your choice to `config.toml`. +In non-interactive mode the default `aws` emulator is used if no config file is found. + +Lifecycle commands operate on the emulators defined in your `config.toml`. +Run a single `[[containers]]` block at a time; the AWS-specific commands (`status` resources, `aws`, `reset`, `setup aws`) require an `aws` emulator to be configured. + +:::note +The AWS emulator's license is validated by `lstk` before the container starts. +The Snowflake and Azure emulators validate their own license inside the container at startup, so `lstk` skips its pre-flight license check for them. +If your license does not include the selected emulator, the container exits and `lstk` reports the missing entitlement. +::: + +## Passing environment variables to the container + +Define reusable environment profiles under `[env.]` and reference them in your container config: + +```toml +[[containers]] +type = "aws" +tag = "latest" +port = "4566" +env = ["debug", "ci"] + +[env.debug] +DEBUG = "1" +ENFORCE_IAM = "1" +PERSISTENCE = "1" + +[env.ci] +SERVICES = "s3,sqs" +EAGER_SERVICE_LOADING = "1" +``` + +When `lstk start` runs, the key-value pairs from each referenced profile are injected as environment variables into the LocalStack container. +Keys are uppercased automatically. + +:::note +If you reference an `env` profile name that doesn't exist in your config, `lstk` returns an error: `environment "..." referenced in container config not found`. +::: + +In addition to your custom profiles, `lstk` always injects several variables into the container. +See [Container-injected variables](/aws/developer-tools/running-localstack/lstk/automation/#container-injected-variables) for the full list. + +## Custom container image + +By default the emulator image is pulled from Docker Hub (`localstack/localstack-pro`, `localstack/snowflake`, or `localstack/localstack-azure` depending on `type`). +Set `image` on a container block to override it — for example, to pull from an internal-registry mirror or to run a locally loaded image in an air-gapped environment: + +```toml +[[containers]] +type = "aws" +image = "registry.internal.example.com/localstack/localstack-pro" +tag = "2026.4" +``` + +If `image` already carries a tag (e.g. `...:2026.4`), the separate `tag` field is ignored; otherwise `tag` (or `latest`) is appended. +See [Offline and enterprise environments](/aws/developer-tools/running-localstack/lstk/setup-and-maintenance/#offline-and-enterprise-environments) for how `lstk` falls back to a locally present image when a pull fails. + +## Volume mounts + +Beyond the single persistence directory set by `volume`, a container block can declare arbitrary Docker-style bind mounts with `volumes`. +Each entry is a `"host:container[:ro]"` spec — useful, for example, for mounting a [Snowflake init hook](/snowflake/capabilities/init-hooks/) script into `/etc/localstack/init/{boot,start,ready,shutdown}.d`: + +```toml +[[containers]] +type = "snowflake" +port = "4566" +volumes = [ + "./test.sf.sql:/etc/localstack/init/ready.d/test.sf.sql", + "./data:/var/lib/localstack", +] +``` + +- A `volumes` entry whose container target is `/var/lib/localstack` sets the persistence directory (the same mount `volume` configures); this is what [`lstk volume path`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#volume) and [`lstk volume clear`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#volume) resolve. +- Relative host sources and a leading `~/` are resolved against the config file's directory. This differs from the legacy `volume` field, whose value is passed to Docker verbatim. +- Setting the persistence directory through both `volume` and a `volumes` entry with a different source is a validation error. + +`volume` and `volumes` overlap only for the persistence mount: `volume` can *only* set the persistence directory, while `volumes` is a superset that can also express init hooks and other mounts. + +## Using a project-local config + +Place a `.lstk/config.toml` in your project directory. +When you run `lstk` from that directory, the local config takes precedence over the global one. +This lets each project pin its own emulator type, image tag, and environment profiles. + +For example, a project that targets the Snowflake emulator can keep its own config: + +```toml +# .lstk/config.toml +[[containers]] +type = "snowflake" +port = "4566" +``` + +An AWS project might instead pin a specific image tag and enable a debug profile: + +```toml +# .lstk/config.toml +[[containers]] +type = "aws" +tag = "2026.4" +port = "4566" +env = ["dev"] + +[env.dev] +DEBUG = "1" +PERSISTENCE = "1" +``` diff --git a/src/content/docs/aws/developer-tools/running-localstack/lstk/faq-and-troubleshooting.md b/src/content/docs/aws/developer-tools/running-localstack/lstk/faq-and-troubleshooting.md new file mode 100644 index 00000000..eea8e91c --- /dev/null +++ b/src/content/docs/aws/developer-tools/running-localstack/lstk/faq-and-troubleshooting.md @@ -0,0 +1,149 @@ +--- +title: lstk FAQ & Troubleshooting +description: Frequently asked questions and common issues when using lstk. +template: doc +tags: ['Hobby'] +--- + +## FAQ + +### Can I use `lstk` with Docker Compose? + +No. `lstk` manages its own Docker container directly. +If you use a `docker-compose.yml` to run LocalStack, you do not need `lstk`, and vice versa. +Do not mix `lstk start` with a Docker Compose setup; they are separate, independent methods. + +For Docker Compose configuration, see the [Docker Compose installation guide](/aws/getting-started/installation/#docker-compose). + +### Which Docker image does `lstk` use? + +It depends on the emulator type configured in your `config.toml`. +The AWS emulator uses `localstack/localstack-pro`, the Snowflake emulator uses `localstack/snowflake`, and the Azure emulator uses `localstack/localstack-azure`. +All require a valid auth token (including the free Hobby tier). +See [Emulator types](/aws/developer-tools/running-localstack/lstk/configuration/#emulator-types). + +### How do I pass configuration options like `DEBUG` or `PERSISTENCE` to the container? + +Use environment profiles in your `config.toml`. +Define the variables under an `[env.]` section and reference that name in the `env` list of your container config. +See [Passing environment variables to the container](/aws/developer-tools/running-localstack/lstk/configuration/#passing-environment-variables-to-the-container) for details. + +### How do I save and restore emulator state? + +Use [`lstk snapshot save`](/aws/developer-tools/running-localstack/lstk/snapshots/#snapshot-save) to capture the running AWS emulator's state to a local file or a Cloud Pod, and [`lstk snapshot load`](/aws/developer-tools/running-localstack/lstk/snapshots/#snapshot-load) (or the `lstk save` / `lstk load` aliases) to restore it. +To drop in-memory state without writing a snapshot, use [`lstk reset`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#reset). + +### How do I pin a specific LocalStack version? + +Set the `tag` field in your `config.toml` to a specific version tag: + +```toml +[[containers]] +type = "aws" +tag = "2026.4" +port = "4566" +``` + +## Troubleshooting + +### Port 443 already in use + +By default, LocalStack binds to both port `4566` and port `443` inside the container (controlled by the `GATEWAY_LISTEN` variable). +On some systems, particularly Windows with Hyper-V, IIS, or VPN software, port 443 may already be in use. + +**Symptoms:** + +```text +failed to start LocalStack: Error response from daemon: ports are not available: +exposing port TCP 127.0.0.1:443 -> 127.0.0.1:0: listen tcp4 127.0.0.1:443: bind: +address already in use +``` + +**Fix:** Override `GATEWAY_LISTEN` to bind only to port 4566: + +```toml +[[containers]] +type = "aws" +tag = "latest" +port = "4566" +env = ["nossl"] + +[env.nossl] +GATEWAY_LISTEN = "0.0.0.0:4566" +``` + +This tells the container to skip the port 443 binding entirely. + +### Docker is not running + +`lstk` requires a running Docker daemon. +If Docker is not reachable, you will see an error like: + +```text +Error: runtime not healthy +``` + +**Fix:** Start Docker Desktop (macOS/Windows) or the Docker daemon (`sudo systemctl start docker` on Linux). +If you use Colima or OrbStack, make sure the VM is running. +You can also point `lstk` at a custom socket with `DOCKER_HOST`. + +### Authentication required in non-interactive mode + +When running without a TTY (e.g. in CI), `lstk` cannot open a browser for login. +If no token is found in the keyring or environment, it fails: + +```text +authentication required: set LOCALSTACK_AUTH_TOKEN or run in interactive mode +``` + +**Fix:** Set the `LOCALSTACK_AUTH_TOKEN` environment variable before running `lstk`: + +```bash +export LOCALSTACK_AUTH_TOKEN= +lstk --non-interactive start +``` + +You can find your auth token on the [Auth Tokens page](https://app.localstack.cloud/workspace/auth-tokens). + +### License validation failed + +If your auth token is invalid, expired, or not linked to an active license, the LocalStack container exits with a license error: + +```text +The license activation failed for the following reason: +No credentials were found in the environment. +``` + +**Fix:** + +- Verify your token is valid at the [Auth Tokens page](https://app.localstack.cloud/workspace/auth-tokens). +- Make sure the token is set correctly, either via `lstk login` or the `LOCALSTACK_AUTH_TOKEN` environment variable. +- A stale token or cached license no longer requires a manual `lstk logout`: when the platform definitively rejects it, `lstk` drops the cached license and, in an interactive terminal, prompts you to log in again and retries automatically. In non-interactive mode, run `lstk logout && lstk login` (or set a valid `LOCALSTACK_AUTH_TOKEN`) and re-run. + +### Image pull failed + +If `lstk` cannot pull the Docker image, check your network connection and Docker configuration. +On corporate networks, you may need to configure Docker's proxy settings, see [How do I configure LocalStack to use my corporate HTTP and HTTPS proxy?](/aws/getting-started/faq/#how-do-i-configure-localstack-to-use-my-corporate-http-and-https-proxy). + +### Unknown environment profile + +If your container config references an `env` profile that doesn't exist, `lstk` returns: + +```text +environment "myprofile" referenced in container config not found +``` + +**Fix:** Make sure the profile name in the `env` list matches an `[env.]` section in your `config.toml`: + +```toml +[[containers]] +type = "aws" +env = ["myprofile"] # must match the section name below + +[env.myprofile] +DEBUG = "1" +``` + +### Getting help + +If the steps above don't resolve your issue, see [Get Help](/aws/help-support/get-help/) for the available support channels, including the support email and in-app chat. diff --git a/src/content/docs/aws/developer-tools/running-localstack/lstk/index.mdx b/src/content/docs/aws/developer-tools/running-localstack/lstk/index.mdx new file mode 100644 index 00000000..fa5d5e62 --- /dev/null +++ b/src/content/docs/aws/developer-tools/running-localstack/lstk/index.mdx @@ -0,0 +1,173 @@ +--- +title: lstk CLI +description: Overview, installation, and quick start for lstk, the modern CLI for managing LocalStack. +template: doc +tags: ['Hobby'] +--- + +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +## Introduction + +`lstk` is a high-performance command-line interface for LocalStack, built in Go. +It provides a built-in terminal UI (TUI) for interactive use and plain text output for CI/CD pipelines and scripting. + +`lstk` handles the full emulator lifecycle: authentication, pulling the Docker image, starting, stopping, and restarting the container, streaming logs, and checking status. +It can also save and load emulator state (as local snapshots or Cloud Pods) reset running state, run AWS CLI commands against the emulator, and manage the on-disk volume. +Running `lstk` with no arguments takes you through the entire startup flow automatically. + +`lstk` also proxies developer tools so they run directly against LocalStack: the AWS CLI (`lstk aws`), the Azure CLI (`lstk az`), Terraform (`lstk terraform`), the AWS CDK (`lstk cdk`), and the AWS SAM CLI (`lstk sam`). + +:::tip[Recommended] +`lstk` is the recommended way to run and manage LocalStack. The [legacy LocalStack CLI](/aws/developer-tools/running-localstack/localstack-cli/) is deprecated. +::: + +This section is split into focused pages: + +- **Overview** (this page): installation, quick start, and shell completions. +- [Authentication](/aws/developer-tools/running-localstack/lstk/authentication/): logging in and out, and how `lstk` resolves your auth token. +- [Configuration](/aws/developer-tools/running-localstack/lstk/configuration/): the `config.toml` file, emulator types, environment variables, and volumes. +- [Lifecycle commands](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/): `start`, `stop`, `restart`, `status`, `logs`, `reset`, `volume`. +- [AWS & IaC commands](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/): `aws`, `az`, `terraform`, `cdk`, `sam`. +- [Snapshots](/aws/developer-tools/running-localstack/lstk/snapshots/): `snapshot save`/`load`/`list`/`remove`/`show`, and S3 remotes. +- [Automation & CI](/aws/developer-tools/running-localstack/lstk/automation/): global options, non-interactive mode, structured output, and environment variables. +- [Setup & maintenance](/aws/developer-tools/running-localstack/lstk/setup-and-maintenance/): `setup`, `config`, `update`, and offline/enterprise environments. +- [FAQ & Troubleshooting](/aws/developer-tools/running-localstack/lstk/faq-and-troubleshooting/). + +## Prerequisites + +- [Docker](https://docs.docker.com/get-docker/) installed and running. +- A [LocalStack account](https://www.localstack.cloud/pricing) with a [license](/aws/getting-started/auth-token/#license-assignment), and `lstk` handles authentication for you (see [Authentication](/aws/developer-tools/running-localstack/lstk/authentication/)). + +## Installation + + + + +```bash +brew install localstack/tap/lstk +``` + +Homebrew also installs shell completions for bash, zsh, and fish automatically. + + + + +```bash +npm install -g @localstack/lstk +``` + + + + +Download the binary for your platform from [GitHub Releases](https://github.com/localstack/lstk/releases), extract it, and place it on your `PATH`. + + + + +Verify the installation: + +```bash +lstk --version +``` + +### Updating + +`lstk` can update itself. +It detects how it was originally installed (Homebrew, npm, or binary) and uses the matching update method: + +```bash +# Check for updates without installing +lstk update --check + +# Update to the latest version +lstk update +``` + +See the [`update`](/aws/developer-tools/running-localstack/lstk/setup-and-maintenance/#update) command for details, including the start-time update notification. + +## Quick start + +```bash +lstk +``` + +Running `lstk` without arguments performs the full startup sequence: authenticates you automatically, pulls the latest image if needed, and starts the LocalStack container. +In an interactive terminal it launches the TUI; in a non-interactive environment it prints plain text output. + +On the very first interactive run, `lstk` prompts you to pick which emulator to run (AWS, Snowflake, or Azure) and writes your choice to `config.toml`. +See [Emulator types](/aws/developer-tools/running-localstack/lstk/configuration/#emulator-types) for the available options. + +For CI or headless environments, set `LOCALSTACK_AUTH_TOKEN` and use `--non-interactive`: + +```bash +LOCALSTACK_AUTH_TOKEN= lstk --non-interactive +``` + +CI environments require a CI Auth Token; a personal Developer Auth Token cannot be used there. + +## Shell completions + +`lstk` includes completion scripts for bash, zsh, fish, and powershell. +If you installed via Homebrew, completions are set up automatically. + +For manual setup: + + + + +```bash +# Load in current session +eval "$(lstk completion bash)" + +# Persist (Linux) +lstk completion bash > /etc/bash_completion.d/lstk + +# Persist (macOS with Homebrew) +lstk completion bash > $(brew --prefix)/etc/bash_completion.d/lstk +``` + +:::note +Use `eval "$(lstk completion bash)"` rather than `source <(lstk completion bash)`. +The `lstk` script works with or without the `bash-completion` package (it bundles a fallback for stock macOS bash 3.2), but `source <(...)` is a silent no-op on that shell. +::: + + + + +```bash +# Load in current session +source <(lstk completion zsh) + +# Persist (Linux) +lstk completion zsh > "${fpath[1]}/_lstk" + +# Persist (macOS with Homebrew) +lstk completion zsh > $(brew --prefix)/share/zsh/site-functions/_lstk +``` + + + + +```bash +# Load in current session +lstk completion fish | source + +# Persist +lstk completion fish > ~/.config/fish/completions/lstk.fish +``` + + + + +Restart your shell after persisting completions. + +### `completion` + +Generate shell completion scripts. + +```bash +lstk completion [bash|zsh|fish|powershell] +``` + +See [Shell completions](#shell-completions) above for setup instructions. diff --git a/src/content/docs/aws/developer-tools/running-localstack/lstk/lifecycle-commands.md b/src/content/docs/aws/developer-tools/running-localstack/lstk/lifecycle-commands.md new file mode 100644 index 00000000..cd96ad91 --- /dev/null +++ b/src/content/docs/aws/developer-tools/running-localstack/lstk/lifecycle-commands.md @@ -0,0 +1,298 @@ +--- +title: lstk Lifecycle Commands +description: The start, stop, restart, status, logs, reset, and volume commands for managing the LocalStack emulator with lstk. +template: doc +tags: ['Hobby'] +--- + +`lstk` uses a flat command structure. +Running `lstk` with no command is equivalent to `lstk start`. + +## `start` + +Start the LocalStack emulator. +Launches the TUI in interactive terminals and prints plain output otherwise. +`lstk start` launches the emulator defined in the first `[[containers]]` entry of the resolved `config.toml` (not necessarily AWS). + +```bash +lstk start +lstk start --persist +lstk start --non-interactive +``` + +| Option | Description | +|:--------------------|:-----------------------------------------------------------------------------| +| `--persist` | Persist emulator state across restarts (sets `LOCALSTACK_PERSISTENCE=1` in the container) | +| `--type `, `-t ` | Select the emulator to start (`aws`, `snowflake`, or `azure`) non-interactively, recording the choice in `config.toml`. See [Selecting the emulator with `--type`](#selecting-the-emulator-with---type). | +| `--snapshot ` | Auto-load this snapshot after the emulator starts, overriding the configured `snapshot` for one run (AWS only) | +| `--no-snapshot` | Skip auto-loading the configured `snapshot` for this run | +| `--timeout ` | Maximum time to wait for the emulator to become ready, as a Go duration (e.g. `90s`, `2m`). Overrides `LSTK_STARTUP_TIMEOUT` for this run; `0` uses the per-mode default. | +| `--non-interactive` | Disable the interactive TUI and use plain output | + +`lstk start` forwards host environment variables prefixed with `LOCALSTACK_` to the emulator (the host `LOCALSTACK_AUTH_TOKEN` is dropped so it cannot override the token `lstk` resolved). See [Container-injected variables](/aws/developer-tools/running-localstack/lstk/automation/#container-injected-variables). + +`lstk` applies a readiness deadline while waiting for the emulator to come up (a crash during startup is detected instantly, with its exit code, and does not wait for the deadline). In an interactive terminal the deadline defaults to 20 seconds and is only a recoverable prompt — you can keep waiting or stop; in non-interactive mode it defaults to 60 seconds and is fatal, leaving the container running for inspection. Override the deadline for a single run with `--timeout` (a Go duration such as `90s` or `2m`), or for every run with [`LSTK_STARTUP_TIMEOUT`](/aws/developer-tools/running-localstack/lstk/automation/#environment-variables); an explicit `--timeout` wins over the environment variable, and `--timeout 0` falls back to the per-mode default. The flag is available on `start` and the bare `lstk` command only — `restart` and the snapshot auto-start path do not expose it. + +By default the emulator starts with a fresh state on every run. +Pass `--persist` to keep data across restarts: `lstk` injects `LOCALSTACK_PERSISTENCE=1` into the container so state is written to the mounted [`volume`](/aws/developer-tools/running-localstack/lstk/configuration/#config-field-reference) and reloaded on the next start. +When persistence is active, the AWS emulator's startup summary includes a `• Persistence: Enabled` line. + +```bash +# Start with persistent state +lstk start --persist +``` + +:::note +`--persist` is a flag on `start` (and the bare `lstk` command) and on [`restart`](#restart). +For finer-grained control, you can also set `PERSISTENCE = "1"` in an environment profile (see [Passing environment variables to the container](/aws/developer-tools/running-localstack/lstk/configuration/#passing-environment-variables-to-the-container)). +::: + +### Selecting the emulator with `--type` + +`--type` (shorthand `-t`, also available on the bare `lstk` command) is the non-interactive answer to the first-run emulator picker. +It selects which emulator to start (`aws`, `snowflake`, or `azure`) and **records the choice in `config.toml`**, so lifecycle commands (`stop`, `status`, `logs`, `volume`, snapshot auto-load) stay in sync with what you started. + +```bash +# Start the Snowflake emulator, recording the choice in config +lstk start --type snowflake + +# Shorthand +lstk start -t azure +``` + +- On first run, the config is created with the selected type. +- If the configured type already matches, `--type` is a no-op. +- If it differs, `lstk` rewrites the `type` line in place (comments and formatting preserved) and prints a note naming the config file. + +When switching an existing config to a different type: + +- A custom `image` is a **hard error** — it pins a specific product that cannot be reinterpreted under a new emulator type. Use a separate config (`--config`) for that profile instead. +- A non-`latest` `tag` and any `volume`/`volumes` mounts are kept, but `lstk` warns that they may be product-specific. +- `port`, `env`, and `snapshot` are kept silently. + +`--type` is a flag only; passing the emulator as a positional (`lstk start azure`) is rejected with a hint pointing at `--type`. + +### Auto-loading a snapshot on start + +For the **AWS emulator**, you can have `lstk` load a snapshot automatically every time it starts the emulator. +Set the `snapshot` field on the container block to any load REF (a `pod:` Cloud Pod or a local path): + +```toml +[[containers]] +type = "aws" +port = "4566" +snapshot = "pod:my-baseline" +``` + +The snapshot is loaded only when the emulator is **freshly started** this run; if it is already running, the auto-load is skipped. +Override it for a single run with `--snapshot REF`, or skip it entirely with `--no-snapshot`: + +```bash +# Start and load a different snapshot for this run only +lstk start --snapshot pod:other-baseline + +# Start without loading the configured snapshot +lstk start --no-snapshot +``` + +The `snapshot` field is only read on start; [`snapshot save`](/aws/developer-tools/running-localstack/lstk/snapshots/#snapshot-save) never writes it back into your config. + +## `stop` + +Stop the running LocalStack emulator. +Stops every emulator container defined in the resolved `config.toml` (the `[[containers]]` entries), with a 30-second stop timeout per container. + +```bash +lstk stop +lstk stop --non-interactive +``` + +`stop` fails fast if the Docker runtime is not healthy (for example, Docker is not running), or if a configured emulator is not currently running (`LocalStack is not running`). +In an interactive terminal it shows an animated "Stopping LocalStack..." spinner and a styled confirmation; in non-interactive mode it prints the same progress and result as plain text. + +`stop` supports [`--json`](/aws/developer-tools/running-localstack/lstk/automation/#structured-output): the `data` payload lists each configured emulator and whether it `wasRunning`. + +## `restart` + +Stop and restart the LocalStack emulator. +Performs a stop of the running emulator followed by a fresh start, using the same auth, config, and Docker settings as [`start`](#start). +Launches the TUI in interactive terminals and prints plain output otherwise. + +```bash +lstk restart +lstk restart --persist +``` + +| Option | Description | +|:-------------|:-------------------------------------------| +| `--persist` | Persist emulator state across the restart | + +By default, emulator state is **not** retained across the restart and the container starts clean. +Pass `--persist` to keep the emulator's state so it survives the restart. + +## `status` + +Show the status of a running emulator and its deployed resources. +Before contacting the emulator, `lstk` checks that the Docker runtime is healthy; if it is not, the command reports `runtime not healthy` and exits with a non-zero status. + +```bash +lstk status +lstk --non-interactive status +``` + +For each emulator configured in your `config.toml` (the `[[containers]]` entries), `status` reports whether it is running and, if so, prints an instance summary: + +```text +LocalStack AWS Emulator is running +• Endpoint: localhost:4566 +• Persistence: Enabled +• Container: localstack-aws +• Version: 4.0.0 +• Uptime: 1h 12m 4s +``` + +- **Endpoint** is the live `host:port`, queried from Docker, so it stays correct even if the configured `port` was changed while the container kept running. +- **Persistence** appears only for the AWS emulator and only when persistence is enabled. +- **Uptime** is computed from the container's start time and is omitted if it cannot be determined. + +If an emulator is not running, `status` prints an error and exits non-zero without checking the remaining emulators: + +```text +LocalStack AWS Emulator is not running + + Start LocalStack: lstk + See help: lstk -h +``` + +For the **AWS emulator**, `status` additionally lists deployed resources. +When resources exist it prints a summary line followed by a table; when none exist it prints `No resources deployed`. + +```text +~ 3 resources · 2 services + +Service Resource Region Account +S3 my-bucket us-east-1 000000000000 +SQS my-queue us-east-1 000000000000 +``` + +In an interactive terminal the output is rendered through the TUI; in non-interactive mode (or with `--non-interactive`) the same content is printed as plain text, with the resource table shown at full width when stdout is not a TTY. +The Snowflake and Azure emulators show the instance summary only and never report resources. + +## `logs` + +Show or stream emulator logs. + +```bash +lstk logs [options] +``` + +| Option | Description | +|:------------|:-----------------------------------------| +| `--follow`, `-f` | Stream logs in real-time. Without this flag, `lstk` prints the currently available logs and exits. | +| `--verbose`, `-v` | Show all logs without filtering. By default, `lstk` drops noisy lines (internal request logs, provider chatter); `--verbose` shows every line verbatim. | +| `--tail `, `-n ` | Show only the last `N` lines from the end of the logs. Accepts a non-negative integer or `all` (the default, showing all available lines). | + +By default, `lstk logs` reads from the first configured emulator container and applies a noise filter. +In an interactive terminal, lines are color-coded by log level (`DEBUG`, `INFO`, `WARN`, `ERROR`); in non-interactive mode, raw log lines are written to stdout. + +Example: + +```bash +# Print current filtered logs and exit +lstk logs + +# Stream filtered logs in real-time +lstk logs --follow + +# Show only the last 100 lines +lstk logs --tail 100 + +# Stream all logs without filtering +lstk logs --follow --verbose +``` + +## `reset` + +Discard the running AWS emulator's in-memory state (all created resources such as S3 buckets and Lambda functions are dropped). +The emulator **keeps running**; only its state is cleared. + +```bash +lstk reset +lstk reset --force +``` + +| Option | Description | +|:----------|:------------------------------------------------------------------| +| `--force` | Skip the confirmation prompt. Required in non-interactive mode. | + +In interactive mode, `reset` prompts for confirmation before clearing state. +In non-interactive mode it fails unless `--force` is passed: + +```text +reset requires confirmation; use --force to skip in non-interactive mode +``` + +`reset` supports [`--json`](/aws/developer-tools/running-localstack/lstk/automation/#structured-output): on success the `data` payload reports the reset emulator and `"reset": true`. + +:::note +`reset` clears in-memory state only. +It does **not** wipe the on-disk volume (certificates, persistence data, cached tools). +To clear that, stop the emulator and run [`lstk volume clear`](#volume-clear). +::: + +## `volume` + +Manage the emulator volume: the host directory that holds persistent state such as certificates, downloaded tools, and persistence data. + +```bash +lstk volume path +lstk volume clear [options] +``` + +### `volume path` + +Prints the resolved volume directory for every emulator in your config, one per line. +With the default config (a single `aws` emulator) it prints one path. +Each path is the container's configured `volume` value, or the default OS cache location if `volume` is unset (`~/Library/Caches/lstk/volume/localstack-aws` on macOS, `~/.cache/lstk/volume/localstack-aws` on Linux). + +```bash +# Print the volume directory for each configured emulator +lstk volume path +``` + +### `volume clear` + +Removes all data from the emulator volume directory, resetting cached state. +It operates on all configured emulators by default, or a single one with `--type`. +Before clearing, it lists each target as `: ()`. + +| Option | Description | +|:----------------|:-----------------------------------------| +| `--force` | Skip the confirmation prompt | +| `--type ` | Clear only the emulator of this type | + +```bash +# Clear all configured emulator volumes (prompts for confirmation) +lstk volume clear + +# Clear only the AWS emulator volume +lstk volume clear --type aws + +# Skip the confirmation prompt +lstk volume clear --force + +# Clear without prompting in a non-interactive environment +lstk volume clear --type snowflake --force +``` + +In an interactive terminal, `lstk volume clear` prompts `Clear volume data? This cannot be undone` before deleting anything; choosing **NO** or pressing Ctrl+C cancels with no changes. +In non-interactive mode, `--force` is required, otherwise the command fails with `volume clear requires confirmation; use --force to skip in non-interactive mode`. + +:::caution +If the volume contains files owned by `root` (created by Docker), clearing fails with a permission error. +Re-run with elevated privileges: + +```bash +sudo lstk volume clear +``` +::: diff --git a/src/content/docs/aws/developer-tools/running-localstack/lstk/setup-and-maintenance.md b/src/content/docs/aws/developer-tools/running-localstack/lstk/setup-and-maintenance.md new file mode 100644 index 00000000..230d94f4 --- /dev/null +++ b/src/content/docs/aws/developer-tools/running-localstack/lstk/setup-and-maintenance.md @@ -0,0 +1,181 @@ +--- +title: lstk Setup & Maintenance +description: The setup, config, and update commands, and running lstk in offline or enterprise environments. +template: doc +tags: ['Hobby'] +--- + +## `setup` + +Set up CLI integration for an emulator type. +`lstk setup` is a grouping command with no action of its own; the work is done by its subcommands, `setup aws` and `setup azure`. + +```bash +lstk setup aws +lstk setup azure +``` + +### `setup aws` + +Create or update a `localstack` profile in `~/.aws/config` and `~/.aws/credentials` so the AWS CLI and SDKs can target LocalStack. + +```bash +lstk setup aws +lstk setup aws --force +``` + +| Option | Description | +|:----------|:-----------------------------------------------------------------------------------------| +| `--force` | Overwrite an existing `localstack` profile whose values differ, and skip the confirmation prompt. | + +On an interactive terminal it prompts (Y/n) before making changes. +In non-interactive mode (piped output, CI, or `--non-interactive`) it writes the profile with defaults without prompting and exits `0`; a failed write or check returns a non-zero exit code so automation notices. +Overwriting an existing `localstack` profile whose values differ requires `--force` (which also skips the interactive prompt); creating a fresh profile, completing a partial one, or leaving an already-correct profile in place never needs it. + +It writes the following profile (existing unrelated profiles are preserved): + +```ini +# ~/.aws/config +[profile localstack] +region = us-east-1 +output = json +endpoint_url = http://localhost.localstack.cloud:4566 + +# ~/.aws/credentials +[localstack] +aws_access_key_id = test +aws_secret_access_key = test +``` + +Afterwards, target LocalStack by passing `--profile localstack` or exporting `AWS_PROFILE`: + +```bash +export AWS_PROFILE=localstack +aws s3 ls +``` + +The endpoint host is resolved the same way as for [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#endpoint-resolution) (probing `localhost.localstack.cloud` and falling back to `127.0.0.1`), and [`LOCALSTACK_HOST`](/aws/developer-tools/running-localstack/lstk/automation/#environment-variables) overrides the host and port written into the profile. +The port comes from your AWS emulator's configured `port` (default `4566`); if no `aws` emulator is configured, the command fails with `no aws emulator configured`. + +If the `localstack` profile is already configured correctly, `lstk` reports `LocalStack AWS profile is already configured.` and makes no changes. + +:::note +The former `lstk config profile` command has been removed; use `lstk setup aws`. +::: + +### `setup azure` + +Prepare an isolated Azure CLI configuration directory (under the `lstk` config dir, via `AZURE_CONFIG_DIR`) that routes [`lstk az`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#az) commands to the LocalStack Azure emulator. +Your global `~/.azure` configuration is left untouched. + +```bash +lstk setup azure +# alias: +lstk setup az +``` + +`setup azure` registers a custom Azure cloud (`LocalStack`) whose endpoints point at the LocalStack Azure emulator, activates it, disables Azure CLI instance discovery and telemetry, and performs a one-time dummy service-principal login — all inside a dedicated config directory under the `lstk` config dir (via `AZURE_CONFIG_DIR`). +It requires the `az` CLI to be installed and a running LocalStack Azure emulator. + +Run this once; afterwards use `lstk az ` to run Azure CLI commands against LocalStack. +To instead redirect your **global** `az` (so existing scripts run unmodified against LocalStack), see [`lstk az start-interception`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#global-interception-optional). + +## `config` + +Manage CLI configuration. +`config` has no behavior of its own; run it with a subcommand. + +### `config path` + +Print the resolved path to the active `config.toml`. + +```bash +lstk config path +``` + +This subcommand is read-only: it never creates or initializes a config file. +If `--config ` is set, it prints that path verbatim. +Otherwise it prints the already-loaded config path, the first existing config in the search order, or the path where a config would be created on first run. + +## `update` + +Check for and apply updates to the `lstk` CLI itself. +`lstk` auto-detects how it was installed (Homebrew, npm, or direct binary) and updates using that same method. +Development builds (version `dev`) are skipped, and updates are checked against the latest [GitHub release](https://github.com/localstack/lstk/releases/latest). + +```bash +lstk update [options] +``` + +| Option | Description | +|:--------------------|:------------------------------------------------------------| +| `--check` | Check for updates without installing them | +| `--non-interactive` | Use plain output instead of the TUI (update logic unchanged) | +| `--json` | Emit the result as a JSON envelope (see [Structured output](/aws/developer-tools/running-localstack/lstk/automation/#structured-output)). With `--check`, `data` reports `currentVersion`/`latestVersion`/`updateAvailable`; after an applied update, `updatedVersion`/`updated`/`method`. | + +Examples: + +```bash +# Check for updates without installing +lstk update --check + +# Update to the latest version +lstk update + +# Update with plain (non-TUI) output +lstk update --non-interactive +``` + +By install method: + +- **Homebrew** (binary under a `Caskroom` path): runs `brew upgrade localstack/tap/lstk`. +- **npm** (binary under `node_modules`): runs `npm install -g @localstack/lstk@latest`. +- **Binary** (anything else): downloads the release asset for your OS/arch from GitHub, extracts it, and replaces the running executable in place. + +With `--check`, `lstk` only reports whether a newer version is available and exits without downloading or installing anything. + +:::note +Set `LSTK_GITHUB_TOKEN` to send an authenticated GitHub request and avoid API rate limits during update checks. +It is optional; updates also work unauthenticated. +::: + +If more than one `lstk` installation is found on your `PATH` (for example a Homebrew binary and an npm one), `lstk update` and the start-time update notification print a warning listing each location, its install method, and which one is currently running, so you can tell which binary an update will actually replace. + +### Update notification on start + +Separately from `lstk update`, `lstk` checks for a newer version when you run `lstk start` (the default command), using a short timeout that fails silently if GitHub is unreachable. + +In an interactive terminal, when an update is available `lstk` prints the new version and a release-notes link, then prompts: + +```text +Update lstk to latest version? +> Update now [U] + Remind me next time [R] + Skip this version [S] +``` + +- **Update now [U]**: downloads and applies the update, then asks you to re-run your command. +- **Remind me next time [R]**: does nothing; you are reminded on the next run. +- **Skip this version [S]**: records the version in `config.toml` so you are not prompted about it again. + +In non-interactive mode the notification is not a prompt — `lstk` emits a single note (`Update available: → (run lstk update)`) and continues. + +When you choose **Skip this version**, `lstk` writes the skipped version under a `[cli]` table: + +```toml +[cli] +update_skipped_version = "0.5.0" +``` + +While this value matches the latest available version, the start-time update notification for that version is suppressed. +This key is managed automatically and is not intended to be edited by hand. + +## Offline and enterprise environments + +There is no `--offline` flag. Instead, `lstk` degrades gracefully when common enterprise blockers (Docker Hub unreachable, a proxy/TLS interceptor, or an unreachable license server) prevent an internet request: + +- **Image pull**: if the image pull fails but the image is already present locally, `lstk` warns and uses the local image instead of failing. In interactive mode you can also press Esc to abort an in-progress pull and fall back to the local image. +- **License pre-flight**: when the pinned image is already present locally, `lstk` skips its pre-flight license check so a fully offline start is not blocked; the emulator validates the license itself once it starts. When a check does run, a transport-level failure (offline, proxy, or certificate error) is treated as non-fatal and the emulator validates the license instead. A definitive server rejection (HTTP 400/401/403) is handled differently: `lstk` drops the cached license and, in an interactive terminal, offers to log in again and retries the start once with the refreshed credentials (a rejected token often just predates a license purchase or plan change); in non-interactive mode it fails with an error pointing at `lstk logout && lstk login` or a valid `LOCALSTACK_AUTH_TOKEN`. The pre-flight is also skipped — with a warning — when the license server does not recognize the image *tag format* (for example a `dev` nightly or a custom internal-mirror tag): that is not a verdict on the license, so `lstk` defers to the emulator's own startup check rather than blocking the start. +- **Telemetry and update checks** are best-effort and fail silently when offline. + +Pair this behavior with a custom [`image`](/aws/developer-tools/running-localstack/lstk/configuration/#custom-container-image) that points at an internal-registry mirror or a locally loaded image to run `lstk` in an air-gapped environment. diff --git a/src/content/docs/aws/developer-tools/running-localstack/lstk/snapshots.md b/src/content/docs/aws/developer-tools/running-localstack/lstk/snapshots.md new file mode 100644 index 00000000..5c0ef6db --- /dev/null +++ b/src/content/docs/aws/developer-tools/running-localstack/lstk/snapshots.md @@ -0,0 +1,179 @@ +--- +title: lstk Snapshots +description: Save, load, list, remove, and show emulator snapshots with lstk, including S3 remotes. +template: doc +tags: ['Hobby'] +--- + +## `snapshot` + +Manage emulator snapshots. +A snapshot captures the running emulator's state, either as a local file on disk, as a Cloud Pod on the LocalStack platform, or in your own S3 bucket. +The `snapshot` command groups five subcommands — `save`, `load`, `list`, `remove`, and `show`. The first two are also exposed as the top-level aliases `lstk save` and `lstk load`. + +:::note +Snapshots are best supported on the **AWS emulator**. +`snapshot save`/`load` (and the `save`/`load` aliases) also work for the Snowflake and Azure emulators, but their snapshot support is experimental and not fully tested — `lstk` prints a warning such as `Snapshot support for the snowflake emulator is experimental and not fully tested.` +[`reset`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#reset) remains **AWS-only** and errors out with `reset is only supported for the AWS emulator` otherwise. +::: + +## `snapshot save` + +Save a snapshot of the running emulator's state. +The emulator must already be running; this command does **not** auto-start it. + +```bash +# Auto-named snapshot file in the current directory +lstk snapshot save + +# Save to a specific local path +lstk snapshot save ./my-snapshot + +# Save to a Cloud Pod on the LocalStack platform (requires auth) +lstk snapshot save pod:my-baseline + +# Save to your own S3 bucket (pod name is auto-generated if omitted) +lstk snapshot save my-pod s3://my-bucket/prefix + +# Limit the snapshot to a subset of services +lstk snapshot save --services s3,lambda +``` + +The optional `[destination]` argument takes one of these forms: + +| Destination | Description | +|:---------------------------------|:--------------------------------------------------------------------------------------------------| +| (omitted) | Auto-generates a timestamped snapshot file in the current directory (`./snapshot--.snapshot`). | +| local path | Writes a snapshot archive to that path. The `.snapshot` extension is forced. | +| `pod:` | Saves a Cloud Pod to the LocalStack platform. Requires authentication. | +| ` s3://bucket/prefix` | Saves to your own S3 bucket. The pod name is a separate positional (auto-generated when omitted). See [S3 remotes](#s3-remotes). | + +Pod operations require an auth token (`LOCALSTACK_AUTH_TOKEN` or a prior `lstk login`); local-file snapshots do not. + +By default a snapshot captures every service's state. Pass `-s`/`--services` with a comma-separated list to limit it to a subset; this applies uniformly to local files, `pod:` Cloud Pods, and `s3://` remotes. + +| Option | Description | +|:--------------------|:------------------------------------------------------------------------------------------------| +| `--services `, `-s ` | Comma-separated list of services to include in the snapshot (all services by default). Applies to local, `pod:`, and `s3://` destinations. | +| `--profile ` | AWS profile to read S3 credentials from (used only for `s3://` destinations). Defaults to `AWS_*` env vars, then `AWS_PROFILE`. | + +## `snapshot load` + +Load a snapshot into the emulator, **auto-starting it first** if it is not already running. + +```bash +# Load a local snapshot by path or name +lstk snapshot load my-baseline +lstk snapshot load ./checkpoint + +# Load from a Cloud Pod (requires auth) +lstk snapshot load pod:my-baseline + +# Load from your own S3 bucket (pod name is required) +lstk snapshot load my-pod s3://my-bucket/prefix + +# Control how the snapshot merges with running state +lstk snapshot load pod:my-baseline --merge=overwrite + +# Preview what a Cloud Pod load would change, without applying it +lstk snapshot load pod:my-baseline --dry-run +``` + +The `REF` argument is required and identifies a local path/name or a `pod:` Cloud Pod. +To load from S3, pass the pod name followed by an `s3://bucket/prefix` location (see [S3 remotes](#s3-remotes)). + +| Option | Description | +|:---------------------|:------------------------------------------------------------------------------------------------------------| +| `--merge ` | How the loaded state combines with running state. One of `account-region-merge` (default), `overwrite`, `service-merge`. | +| `--dry-run` | Preview the resource additions and modifications the load would produce, per service, without changing any state. Supported for `pod:` refs only; requires a running emulator (it does not auto-start one). | +| `--profile ` | AWS profile to read S3 credentials from (used only for `s3://` sources). Defaults to `AWS_*` env vars, then `AWS_PROFILE`. | + +- `account-region-merge` (default): the snapshot wins on any `(service, account, region)` overlap. +- `overwrite`: running state is reset first, then the snapshot is imported onto a clean state. +- `service-merge`: the snapshot wins per resource; non-overlapping resources are combined. + +Set [`LSTK_MERGE_STRATEGY`](/aws/developer-tools/running-localstack/lstk/automation/#environment-variables) to change the default strategy used when `--merge` is not passed; an explicit `--merge` always wins. + +Pass `--dry-run` with a `pod:` ref to preview a load before committing to it: `lstk` queries the platform and prints, per service, how many resources the snapshot would add or modify under the chosen merge strategy, without touching running state. It is supported for `pod:` refs only (other refs are rejected) and requires the emulator to already be running, since it does not auto-start one. + +The aliases behave identically: + +```bash +lstk save pod:my-baseline +lstk load ./checkpoint +``` + +## `snapshot list` + +List the Cloud Pod snapshots available on the LocalStack platform. +By default, only snapshots you created are listed; pass `--all` to include every snapshot in your organization. +This subcommand operates on Cloud Pods, so it requires authentication. + +```bash +# Snapshots you created +lstk snapshot list + +# Every snapshot in your organization +lstk snapshot list --all + +# List snapshots in your own S3 bucket (requires a running emulator) +lstk snapshot list s3://my-bucket/prefix +``` + +Passing an `s3://bucket/prefix` location lists snapshots stored in your own S3 bucket instead of the platform (see [S3 remotes](#s3-remotes)). Unlike the platform listing, this queries the emulator, so it requires a running emulator. + +| Option | Description | +|:--------------------|:--------------------------------------------------------------| +| `--all` | List all snapshots in your organization, not just your own. | +| `--profile ` | AWS profile to read S3 credentials from (used only with an `s3://` location). Defaults to `AWS_*` env vars, then `AWS_PROFILE`. | + +## `snapshot remove` + +Delete a Cloud Pod snapshot from the LocalStack platform. +Only cloud snapshots (the `pod:` prefix) can be removed; local snapshots are plain files you delete yourself. +This operation cannot be undone. + +```bash +lstk snapshot remove pod:my-baseline + +# Skip the confirmation prompt (required in non-interactive mode) +lstk snapshot remove pod:my-baseline --force +``` + +The required `REF` argument must be a `pod:` Cloud Pod reference. + +| Option | Description | +|:----------|:-------------------------------------------------------------------------| +| `--force` | Skip the confirmation prompt. Required when running non-interactively. | + +## `snapshot show` + +Show metadata for a single Cloud Pod snapshot on the LocalStack platform: its name, created date, size, LocalStack version, message, the services it contains, and per-service resource counts (resource counts render only when the platform has them for that snapshot). +This subcommand is cloud-only and requires authentication. + +```bash +lstk snapshot show pod:my-baseline +``` + +The required `REF` argument must be a `pod:` Cloud Pod reference. + +## S3 remotes + +`snapshot save`, `load`, and `list` can target a snapshot stored in your **own S3 bucket** by passing an `s3://bucket/prefix` location. +The pod name (the snapshot's identity within the bucket) is a positional separate from the `s3://` location — required for `load`, auto-generated for `save` when omitted, and unused for `list`. + +```bash +lstk snapshot save my-pod s3://my-bucket/prefix +lstk snapshot load my-pod s3://my-bucket/prefix +lstk snapshot list s3://my-bucket/prefix +``` + +Credentials follow AWS CLI precedence: `--profile ` wins, otherwise the static `AWS_ACCESS_KEY_ID`/`AWS_SECRET_ACCESS_KEY` (plus optional `AWS_SESSION_TOKEN`) environment variables, otherwise the profile named by `AWS_PROFILE`. +Only static credentials are supported (no SSO, assume-role, or `credential_process`), and credentials must never be embedded in the URL. + +`lstk` runs a pre-flight check that the target bucket exists and errors out rather than letting the emulator auto-create a bucket on a typo. +Because the transfer is performed by the emulator (not the CLI), S3 remotes require a **running emulator**, and `list s3://…` in particular queries the emulator rather than the platform API. + +:::note +`remove` and `show` do not support S3; they operate on Cloud Pods only. +::: diff --git a/src/content/docs/aws/developer-tools/security-testing/explainable-iam.md b/src/content/docs/aws/developer-tools/security-testing/explainable-iam.md index bf330269..f4a0cc26 100644 --- a/src/content/docs/aws/developer-tools/security-testing/explainable-iam.md +++ b/src/content/docs/aws/developer-tools/security-testing/explainable-iam.md @@ -16,7 +16,7 @@ Enable `DEBUG=1` to surface the full log output. ## Getting started -This guide is designed for users new to Explainable IAM and assumes basic knowledge of the AWS CLI and our [`lstk aws` AWS CLI proxy](/aws/developer-tools/running-localstack/lstk#aws). +This guide is designed for users new to Explainable IAM and assumes basic knowledge of the AWS CLI and our [`lstk aws` AWS CLI proxy](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws). Start your LocalStack container with the `DEBUG=1` and `ENFORCE_IAM=1` environment variables set: diff --git a/src/content/docs/aws/developer-tools/security-testing/iam-policy-stream.md b/src/content/docs/aws/developer-tools/security-testing/iam-policy-stream.md index 8f06dd3b..fb756679 100644 --- a/src/content/docs/aws/developer-tools/security-testing/iam-policy-stream.md +++ b/src/content/docs/aws/developer-tools/security-testing/iam-policy-stream.md @@ -23,7 +23,7 @@ Continue using the legacy [LocalStack CLI](/aws/developer-tools/running-localsta ## Getting started This guide is designed for users who are new to the IAM Policy Stream. -It assumes you have basic knowledge of the AWS CLI (and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk#aws) AWS CLI proxy). +It assumes you have basic knowledge of the AWS CLI (and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) AWS CLI proxy). ### Start your LocalStack container diff --git a/src/content/docs/aws/developer-tools/snapshots/cloud-pods.mdx b/src/content/docs/aws/developer-tools/snapshots/cloud-pods.mdx index 709ec239..d655286a 100644 --- a/src/content/docs/aws/developer-tools/snapshots/cloud-pods.mdx +++ b/src/content/docs/aws/developer-tools/snapshots/cloud-pods.mdx @@ -37,7 +37,7 @@ retains your data long-term. If your organization requires snapshots to remain w ## Using the `lstk` CLI -You can save and load snapshots to or from your Cloud Pods repository using the [`lstk snapshot`](/aws/developer-tools/running-localstack/lstk/#snapshot) command. +You can save and load snapshots to or from your Cloud Pods repository using the [`lstk snapshot`](/aws/developer-tools/running-localstack/lstk/snapshots/#snapshot) command. ```bash lstk snapshot --help @@ -216,7 +216,7 @@ lstk snapshot load pod:sample-application:1 • Services: s3 ``` -Comprehensive instructions on using the `lstk snapshot` CLI command are found in the [`lstk` CLI Guide](/aws/developer-tools/running-localstack/lstk/#snapshot). +Comprehensive instructions on using the `lstk snapshot` CLI command are found in the [`lstk` CLI Guide](/aws/developer-tools/running-localstack/lstk/snapshots/#snapshot). :::note The snapshots stored in a Cloud Pod may not remain compatible if used with a different version of LocalStack. @@ -299,7 +299,7 @@ To confirm the successful injection of the container state, visit the respective In addition to loading snapshots through the Command-Line Interface (CLI) or the Console, you can configure the automatic loading of one or more Cloud Pods upon the startup of the LocalStack instance. -The recommended way to automatically load a snapshot from a Cloud Pod at startup is to set the `snapshot` field in your `lstk` [`config.toml`](/aws/developer-tools/running-localstack/lstk/#auto-loading-a-snapshot-on-start). +The recommended way to automatically load a snapshot from a Cloud Pod at startup is to set the `snapshot` field in your `lstk` [`config.toml`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#auto-loading-a-snapshot-on-start). However, if you run the LocalStack container directly, for example via Docker Compose or `docker run`, you can instead use the `AUTO_LOAD_POD` [configuration variable](/aws/customization/configuration-options/). `AUTO_LOAD_POD` can accept multiple Cloud Pod names separated by commas. @@ -309,7 +309,7 @@ When autoloading multiple Cloud Pods, later pods might overwrite the state of ea -Set the `snapshot` field on the container block in your [`config.toml`](/aws/developer-tools/running-localstack/lstk/#auto-loading-a-snapshot-on-start) to the Cloud Pod's `pod:` REF: +Set the `snapshot` field on the container block in your [`config.toml`](/aws/developer-tools/running-localstack/lstk/lifecycle-commands/#auto-loading-a-snapshot-on-start) to the Cloud Pod's `pod:` REF: ```toml [[containers]] diff --git a/src/content/docs/aws/developer-tools/snapshots/saving-snapshots-locally.md b/src/content/docs/aws/developer-tools/snapshots/saving-snapshots-locally.md index 5d8a749d..62aafd19 100644 --- a/src/content/docs/aws/developer-tools/snapshots/saving-snapshots-locally.md +++ b/src/content/docs/aws/developer-tools/snapshots/saving-snapshots-locally.md @@ -13,7 +13,7 @@ Loading a snapshot is significantly faster, and far more convenient, than re-cre ## Using the `lstk` CLI -The [`lstk` CLI](/aws/developer-tools/running-localstack/lstk/#snapshot) lets you save your instance's state to a local file and load it back into another instance at a later time. +The [`lstk` CLI](/aws/developer-tools/running-localstack/lstk/snapshots/#snapshot) lets you save your instance's state to a local file and load it back into another instance at a later time. For example, starting from an empty emulator instance, create an S3 bucket, an SNS topic, and an SQS queue: diff --git a/src/content/docs/aws/developer-tools/snapshots/saving-snapshots-to-s3.md b/src/content/docs/aws/developer-tools/snapshots/saving-snapshots-to-s3.md index 874adc8b..78725829 100644 --- a/src/content/docs/aws/developer-tools/snapshots/saving-snapshots-to-s3.md +++ b/src/content/docs/aws/developer-tools/snapshots/saving-snapshots-to-s3.md @@ -14,7 +14,7 @@ When saving, loading, or listing snapshots in your own S3 bucket, `lstk` uses pr ## Using the `lstk` CLI -The [`lstk snapshot`](/aws/developer-tools/running-localstack/lstk/#snapshot) command lets you save, load, and list snapshots stored in your own S3 bucket by passing an `s3://bucket/prefix` location alongside a snapshot name. +The [`lstk snapshot`](/aws/developer-tools/running-localstack/lstk/snapshots/#snapshot) command lets you save, load, and list snapshots stored in your own S3 bucket by passing an `s3://bucket/prefix` location alongside a snapshot name. The initial step is to export the necessary AWS credentials in your terminal session. @@ -45,7 +45,7 @@ Otherwise LocalStack's [DNS server](/aws/customization/networking/dns-server) re Disable this feature by setting [`DNS_ADDRESS=0`](/aws/customization/configuration-options/) when starting the emulator, which turns off transparent endpoint injection application-wide. On the command line, use `LOCALSTACK_DNS_ADDRESS=0 lstk start` — host variables prefixed with `LOCALSTACK_` are forwarded to the emulator. -In a `config.toml` [environment profile](/aws/developer-tools/running-localstack/lstk/#passing-environment-variables-to-the-container), use the unprefixed form `DNS_ADDRESS = "0"`. +In a `config.toml` [environment profile](/aws/developer-tools/running-localstack/lstk/configuration/#passing-environment-variables-to-the-container), use the unprefixed form `DNS_ADDRESS = "0"`. ::: Once the snapshot has been saved, you can confirm the presence of the snapshot artifacts in the S3 bucket by running: @@ -85,4 +85,4 @@ lstk snapshot list s3://ls-s3-bucket-example Because data transfer is performed by the emulator rather than the CLI, saving, loading, and listing snapshots in your own S3 bucket require a **running emulator**. ::: -Comprehensive instructions on using the `lstk snapshot` CLI command, including credential resolution order, are found in the [`lstk` CLI Guide](/aws/developer-tools/running-localstack/lstk/#s3-remotes). +Comprehensive instructions on using the `lstk snapshot` CLI command, including credential resolution order, are found in the [`lstk` CLI Guide](/aws/developer-tools/running-localstack/lstk/snapshots/#s3-remotes). diff --git a/src/content/docs/aws/getting-started/installation.mdx b/src/content/docs/aws/getting-started/installation.mdx index 8bead722..bfaf9841 100644 --- a/src/content/docs/aws/getting-started/installation.mdx +++ b/src/content/docs/aws/getting-started/installation.mdx @@ -146,9 +146,9 @@ Installation issues typically fall into one of three areas: getting your chosen ### lstk -If you installed via [`lstk`](#lstk) and LocalStack fails to start, authenticate, or pull its image, see [lstk troubleshooting](/aws/developer-tools/running-localstack/lstk/#troubleshooting). +If you installed via [`lstk`](#lstk) and LocalStack fails to start, authenticate, or pull its image, see [lstk troubleshooting](/aws/developer-tools/running-localstack/lstk/faq-and-troubleshooting/#troubleshooting). -For first-run authentication (browser login, keyring tokens, or `LOCALSTACK_AUTH_TOKEN` in CI), refer to [Authentication](/aws/developer-tools/running-localstack/lstk/#authentication) and the [Auth Token guide](/aws/getting-started/auth-token/). +For first-run authentication (browser login, keyring tokens, or `LOCALSTACK_AUTH_TOKEN` in CI), refer to [Authentication](/aws/developer-tools/running-localstack/lstk/authentication/) and the [Auth Token guide](/aws/getting-started/auth-token/). ### Docker Compose and Docker CLI @@ -171,7 +171,7 @@ Stream container logs using the command that matches your install method: lstk logs ``` -For `lstk` CLI diagnostics (separate from container logs), see [Logging](/aws/developer-tools/running-localstack/lstk/#logging). +For `lstk` CLI diagnostics (separate from container logs), see [Logging](/aws/developer-tools/running-localstack/lstk/automation/#logging). diff --git a/src/content/docs/aws/quickstart-library/application-inspection-tracing.mdx b/src/content/docs/aws/quickstart-library/application-inspection-tracing.mdx index 2366704d..c95efa1e 100644 --- a/src/content/docs/aws/quickstart-library/application-inspection-tracing.mdx +++ b/src/content/docs/aws/quickstart-library/application-inspection-tracing.mdx @@ -172,7 +172,7 @@ Now let's clear the instance and confirm it's actually gone and then restore it: **Expected result:** Return to the [**Stack Overview** tab](https://app.localstack.cloud/inst/default/overview) again. You should see the `messages-api` and `Messages` tables are back. Opening the DynamoDB table in the resource browser and clicking the **Items** tab will show the items you saved before the restart are back as well. Cloud Pods restored the _data_ in the table, not just the table definition. :::note -You can do the same save/restore flow from `lstk` instead of the web applicatin using the `lstk snapshot save` and `lstk snapshot load` commands. For more details, see the [lstk documentation](https://docs.localstack.cloud/aws/developer-tools/running-localstack/lstk/#snapshot). +You can do the same save/restore flow from `lstk` instead of the web applicatin using the `lstk snapshot save` and `lstk snapshot load` commands. For more details, see the [lstk documentation](https://docs.localstack.cloud/aws/developer-tools/running-localstack/lstk/snapshots/#snapshot). ::: ### Step 5: Trace the request flow with App Inspector diff --git a/src/content/docs/aws/services/account.mdx b/src/content/docs/aws/services/account.mdx index 2a81139d..80f29274 100644 --- a/src/content/docs/aws/services/account.mdx +++ b/src/content/docs/aws/services/account.mdx @@ -23,7 +23,7 @@ It's important to note that LocalStack doesn't offer a programmatic interface to ## Getting started -This guide is designed for users who are new to Account and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users who are new to Account and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to put contact information, fetch account details, and attach an alternate contact to your account. diff --git a/src/content/docs/aws/services/acm-pca.mdx b/src/content/docs/aws/services/acm-pca.mdx index 5c01e07e..acd96b32 100644 --- a/src/content/docs/aws/services/acm-pca.mdx +++ b/src/content/docs/aws/services/acm-pca.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users who are new to ACM PCA and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users who are new to ACM PCA and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. We will follow the procedure to create and install a certificate for a single-level hierarchy CA hosted by ACM PCA. ### Create a CA diff --git a/src/content/docs/aws/services/acm.mdx b/src/content/docs/aws/services/acm.mdx index d923b023..44d52029 100644 --- a/src/content/docs/aws/services/acm.mdx +++ b/src/content/docs/aws/services/acm.mdx @@ -20,7 +20,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users who are new to ACM and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users who are new to ACM and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. ### Request a public certificate diff --git a/src/content/docs/aws/services/apigateway.mdx b/src/content/docs/aws/services/apigateway.mdx index 4118802f..f1b68bd3 100644 --- a/src/content/docs/aws/services/apigateway.mdx +++ b/src/content/docs/aws/services/apigateway.mdx @@ -21,7 +21,7 @@ The supported APIs are available on the API coverage section for [API Gateway V1 ## Getting started -This guide is designed for users new to API Gateway and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to API Gateway and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will use the Lambda proxy integration to integrate an API method with a Lambda function. diff --git a/src/content/docs/aws/services/appconfig.mdx b/src/content/docs/aws/services/appconfig.mdx index 61853e68..e8effc44 100644 --- a/src/content/docs/aws/services/appconfig.mdx +++ b/src/content/docs/aws/services/appconfig.mdx @@ -15,7 +15,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to AppConfig and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to AppConfig and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an AppConfig application, environment, configuration profiles & feature flags, and deploy the configuration with the AWS CLI. diff --git a/src/content/docs/aws/services/application-autoscaling.mdx b/src/content/docs/aws/services/application-autoscaling.mdx index 0658f311..210083ce 100644 --- a/src/content/docs/aws/services/application-autoscaling.mdx +++ b/src/content/docs/aws/services/application-autoscaling.mdx @@ -19,7 +19,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting Started -This guide is designed for users new to Application Auto Scaling and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Application Auto Scaling and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can configure auto scaling to handle a heavy workload for your Lambda function. diff --git a/src/content/docs/aws/services/appsync.mdx b/src/content/docs/aws/services/appsync.mdx index 0bc0cb7e..adf32d90 100644 --- a/src/content/docs/aws/services/appsync.mdx +++ b/src/content/docs/aws/services/appsync.mdx @@ -14,7 +14,7 @@ AWS AppSync is a fully managed API management service that connects applications LocalStack allows you to use the AppSync APIs in your local environment to connect your applications and services to data and events. The supported APIs are available on our [API Coverage section](#api-coverage), which provides information on the extent of AppSync's integration with LocalStack. -This guide is designed for users new to **AppSync** in LocalStack, and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to **AppSync** in LocalStack, and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. LocalStack supports two primary ways to work with AppSync, GraphQL and Events API. @@ -32,7 +32,7 @@ Use schemas and resolvers to interact with data sources like DynamoDB. Create serverless GraphQL APIs to query databases, microservices, and other APIs. AppSync allows you to define your data models and business logic using a declarative approach, and connect to various data sources, including other AWS services, relational databases, and custom data sources. -This guide is designed for users new to AppSync and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to AppSync and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an AppSync API with a DynamoDB data source using the AWS CLI. diff --git a/src/content/docs/aws/services/athena.mdx b/src/content/docs/aws/services/athena.mdx index 944765b7..3b11e689 100644 --- a/src/content/docs/aws/services/athena.mdx +++ b/src/content/docs/aws/services/athena.mdx @@ -19,7 +19,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Athena and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Athena and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an Athena table and run a query against it in addition to reading the results with the AWS CLI. @@ -124,7 +124,7 @@ wget https://localstack-assets.s3.amazonaws.com/aws-sample-athena-delta-lake.zip unzip aws-sample-athena-delta-lake.zip; rm aws-sample-athena-delta-lake.zip ``` -We can then create an S3 bucket in LocalStack using the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command line, and upload the files to the bucket: +We can then create an S3 bucket in LocalStack using the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command line, and upload the files to the bucket: ```bash lstk aws s3 mb s3://test diff --git a/src/content/docs/aws/services/autoscaling.mdx b/src/content/docs/aws/services/autoscaling.mdx index 7b37523d..5ca4c43a 100644 --- a/src/content/docs/aws/services/autoscaling.mdx +++ b/src/content/docs/aws/services/autoscaling.mdx @@ -16,7 +16,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Auto Scaling and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Auto Scaling and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can create a launch template, an Auto Scaling group, and attach an instance to the Auto Scaling group using the AWS CLI. diff --git a/src/content/docs/aws/services/backup.mdx b/src/content/docs/aws/services/backup.mdx index d3ef5cec..3c99271d 100644 --- a/src/content/docs/aws/services/backup.mdx +++ b/src/content/docs/aws/services/backup.mdx @@ -19,7 +19,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Backup and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Backup and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a backup job and specify a set of resources to the backup plan name and backup rules with the AWS CLI. diff --git a/src/content/docs/aws/services/batch.mdx b/src/content/docs/aws/services/batch.mdx index 64a814e2..80f20fd2 100644 --- a/src/content/docs/aws/services/batch.mdx +++ b/src/content/docs/aws/services/batch.mdx @@ -19,7 +19,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to AWS Batch and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to AWS Batch and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you create and run a Batch job by following these steps: diff --git a/src/content/docs/aws/services/bedrock.mdx b/src/content/docs/aws/services/bedrock.mdx index ac883afe..1abe75d2 100644 --- a/src/content/docs/aws/services/bedrock.mdx +++ b/src/content/docs/aws/services/bedrock.mdx @@ -16,7 +16,7 @@ The supported APIs are available on the API coverage section for [Bedrock](#api- ## Getting started -This guide is designed for users new to AWS Bedrock and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to AWS Bedrock and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method with or without pre-warming the Bedrock engine. We will demonstrate how to use Bedrock by following these steps: diff --git a/src/content/docs/aws/services/ce.mdx b/src/content/docs/aws/services/ce.mdx index 1c195737..1b3b04dc 100644 --- a/src/content/docs/aws/services/ce.mdx +++ b/src/content/docs/aws/services/ce.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Cost Explorer and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Cost Explorer and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to mock the Cost Explorer APIs with the AWS CLI. diff --git a/src/content/docs/aws/services/cloudcontrol.mdx b/src/content/docs/aws/services/cloudcontrol.mdx index 13688a83..c1d8220e 100644 --- a/src/content/docs/aws/services/cloudcontrol.mdx +++ b/src/content/docs/aws/services/cloudcontrol.mdx @@ -16,7 +16,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Cloud Control and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Cloud Control and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to get and list resources using the Cloud Control API. diff --git a/src/content/docs/aws/services/cloudformation.mdx b/src/content/docs/aws/services/cloudformation.mdx index 4f340fb1..899467c6 100644 --- a/src/content/docs/aws/services/cloudformation.mdx +++ b/src/content/docs/aws/services/cloudformation.mdx @@ -56,7 +56,7 @@ The [API Coverage section](#api-coverage) and [feature coverage](#feature-covera ## Getting started -This guide is designed for users new to CloudFormation and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to CloudFormation and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to deploy a simple CloudFormation stack consisting of a single S3 Bucket with the AWS CLI. diff --git a/src/content/docs/aws/services/cloudfront.mdx b/src/content/docs/aws/services/cloudfront.mdx index 799a31e7..0bd6c5d9 100644 --- a/src/content/docs/aws/services/cloudfront.mdx +++ b/src/content/docs/aws/services/cloudfront.mdx @@ -21,7 +21,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started This guide is intended for users who wish to get more acquainted with CloudFront over LocalStack. -It assumes you have basic knowledge of the AWS CLI (and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command). +It assumes you have basic knowledge of the AWS CLI (and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command). Start your LocalStack container using your preferred method. We will demonstrate how you can create an S3 bucket, put a text file named `hello.txt` to the bucket, and then create a CloudFront distribution which makes the file accessible via a `https://abc123.cloudfront.net/hello.txt` proxy URL (where `abc123` is a placeholder for the real distribution ID). diff --git a/src/content/docs/aws/services/cloudtrail.mdx b/src/content/docs/aws/services/cloudtrail.mdx index dee9146c..14240158 100644 --- a/src/content/docs/aws/services/cloudtrail.mdx +++ b/src/content/docs/aws/services/cloudtrail.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to CloudTrail and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to CloudTrail and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to enable S3 object logging to CloudTrail using AWS CLI. diff --git a/src/content/docs/aws/services/cloudwatch.mdx b/src/content/docs/aws/services/cloudwatch.mdx index 2e3355c5..6a4e0a43 100644 --- a/src/content/docs/aws/services/cloudwatch.mdx +++ b/src/content/docs/aws/services/cloudwatch.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to CloudWatch and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to CloudWatch and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method and deploy your Lambda functions that will generate some logs. You can get the name for your Lambda Functions using the [`ListFunctions`](https://docs.aws.amazon.com/lambda/latest/dg/API_ListFunctions.html) API. diff --git a/src/content/docs/aws/services/codeartifact.mdx b/src/content/docs/aws/services/codeartifact.mdx index 663b0892..c6bad940 100644 --- a/src/content/docs/aws/services/codeartifact.mdx +++ b/src/content/docs/aws/services/codeartifact.mdx @@ -21,7 +21,7 @@ It also has full support to create and use NPM repositories. This guide will help you create a domain, repository, and manage package publishing workflows using the `lstk aws` command. -Basic knowledge of the AWS CLI and the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command is expected. +Basic knowledge of the AWS CLI and the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command is expected. Start LocalStack using your preferred method. diff --git a/src/content/docs/aws/services/codebuild.mdx b/src/content/docs/aws/services/codebuild.mdx index 8a892acf..2e08b6c7 100644 --- a/src/content/docs/aws/services/codebuild.mdx +++ b/src/content/docs/aws/services/codebuild.mdx @@ -22,7 +22,7 @@ AWS CodeBuild emulation is powered by the [AWS CodeBuild agent](https://docs.aws This tutorial will show you how to use AWS CodeBuild to test and build a deployable version of a Java executable. -It assumes basic knowledge of the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command, Apache Maven, and Java. +It assumes basic knowledge of the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command, Apache Maven, and Java. ### Create the source code diff --git a/src/content/docs/aws/services/codecommit.mdx b/src/content/docs/aws/services/codecommit.mdx index eff9e018..9cfbf6a5 100644 --- a/src/content/docs/aws/services/codecommit.mdx +++ b/src/content/docs/aws/services/codecommit.mdx @@ -19,7 +19,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to CodeCommit and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to CodeCommit and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can create a CodeCommit repository, clone a repository, and push a commit to the repository. diff --git a/src/content/docs/aws/services/codeconnections.mdx b/src/content/docs/aws/services/codeconnections.mdx index e698871a..84ccf436 100644 --- a/src/content/docs/aws/services/codeconnections.mdx +++ b/src/content/docs/aws/services/codeconnections.mdx @@ -20,7 +20,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to CodeConnections and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to CodeConnections and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a connection to a code repository using the CodeConnections API. diff --git a/src/content/docs/aws/services/codedeploy.mdx b/src/content/docs/aws/services/codedeploy.mdx index ca3c10e3..8e335d7a 100644 --- a/src/content/docs/aws/services/codedeploy.mdx +++ b/src/content/docs/aws/services/codedeploy.mdx @@ -19,7 +19,7 @@ The supported operations are listed on the [API Coverage section](#api-coverage) This guide will walk through the process of creating CodeDeploy applications, deployment configuration, deployment groups, and deployments. -Basic knowledge of the AWS CLI and the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command is expected. +Basic knowledge of the AWS CLI and the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command is expected. Start LocalStack using your preferred method. diff --git a/src/content/docs/aws/services/codepipeline.mdx b/src/content/docs/aws/services/codepipeline.mdx index 49598324..2485259c 100644 --- a/src/content/docs/aws/services/codepipeline.mdx +++ b/src/content/docs/aws/services/codepipeline.mdx @@ -18,7 +18,7 @@ The available operations can be found on the [API coverage](#api-coverage) page. ## Getting started In this guide, we will create a simple pipeline that fetches an object from an S3 bucket and uploads it to a different S3 bucket. -It is for users that are new to CodePipeline and have a basic knowledge of the AWS CLI and the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +It is for users that are new to CodePipeline and have a basic knowledge of the AWS CLI and the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start LocalStack using your preferred method. diff --git a/src/content/docs/aws/services/cognito-idp.mdx b/src/content/docs/aws/services/cognito-idp.mdx index ea3f872d..4219c088 100644 --- a/src/content/docs/aws/services/cognito-idp.mdx +++ b/src/content/docs/aws/services/cognito-idp.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [Cognito Identity coverage section](#api ## Getting started -This guide is designed for users new to Cognito and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Cognito and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can create a Cognito user pool and client, and then sign up and authenticate a new user in the pool. diff --git a/src/content/docs/aws/services/config.mdx b/src/content/docs/aws/services/config.mdx index e85acde0..6cb853b3 100644 --- a/src/content/docs/aws/services/config.mdx +++ b/src/content/docs/aws/services/config.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Config and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Config and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to specify the resource types you want Config to record and grant it the needful permissions to access an S3 bucket and SNS topic with the AWS CLI. diff --git a/src/content/docs/aws/services/dsql.mdx b/src/content/docs/aws/services/dsql.mdx index aa9e5a68..f4c24dfd 100644 --- a/src/content/docs/aws/services/dsql.mdx +++ b/src/content/docs/aws/services/dsql.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Aurora DSQL and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Aurora DSQL and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a cluster, inspect it, and clean it up using the AWS CLI. diff --git a/src/content/docs/aws/services/dynamodb.mdx b/src/content/docs/aws/services/dynamodb.mdx index bf171dbd..6c50747e 100644 --- a/src/content/docs/aws/services/dynamodb.mdx +++ b/src/content/docs/aws/services/dynamodb.mdx @@ -18,7 +18,7 @@ DynamoDB emulation is powered by [DynamoDB Local](https://docs.aws.amazon.com/am ## Getting started -This guide is designed for users new to DynamoDB and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to DynamoDB and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create DynamoDB table, along with its replicas, and put an item into the table using the AWS CLI. diff --git a/src/content/docs/aws/services/dynamodbstreams.mdx b/src/content/docs/aws/services/dynamodbstreams.mdx index a23f91d3..b128dfcc 100644 --- a/src/content/docs/aws/services/dynamodbstreams.mdx +++ b/src/content/docs/aws/services/dynamodbstreams.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to DynamoDB Streams and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to DynamoDB Streams and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate the following process using LocalStack: diff --git a/src/content/docs/aws/services/ec2.mdx b/src/content/docs/aws/services/ec2.mdx index 07865a94..9073f9a2 100644 --- a/src/content/docs/aws/services/ec2.mdx +++ b/src/content/docs/aws/services/ec2.mdx @@ -19,7 +19,7 @@ The list of supported APIs can be found on the [API Coverage section](#api-cover ## Getting started -This guide is designed for users new to EC2 and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to EC2 and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. We will demonstrate how to create an EC2 instance that runs a simple Python web server. LocalStack for AWS running on a Linux host is required as network access to containers is not possible on macOS. diff --git a/src/content/docs/aws/services/ecr.mdx b/src/content/docs/aws/services/ecr.mdx index 56bb8489..4ed066f9 100644 --- a/src/content/docs/aws/services/ecr.mdx +++ b/src/content/docs/aws/services/ecr.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Elastic Container Registry and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Elastic Container Registry and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to build and push a Docker image to a local ECR repository. diff --git a/src/content/docs/aws/services/ecs.mdx b/src/content/docs/aws/services/ecs.mdx index b3112171..6a32812d 100644 --- a/src/content/docs/aws/services/ecs.mdx +++ b/src/content/docs/aws/services/ecs.mdx @@ -19,7 +19,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting Started -This guide is designed for users new to ECS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to ECS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an ECS service using the AWS CLI diff --git a/src/content/docs/aws/services/efs.mdx b/src/content/docs/aws/services/efs.mdx index 33628966..60c2630d 100644 --- a/src/content/docs/aws/services/efs.mdx +++ b/src/content/docs/aws/services/efs.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Elastic File System and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Elastic File System and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a file system, apply an IAM resource-based policy, and create a lifecycle configuration using the AWS CLI. diff --git a/src/content/docs/aws/services/eks.mdx b/src/content/docs/aws/services/eks.mdx index bc4e38b5..332e3989 100644 --- a/src/content/docs/aws/services/eks.mdx +++ b/src/content/docs/aws/services/eks.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Elastic Kubernetes Service and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Elastic Kubernetes Service and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. To interact with the Kubernetes cluster, you should also install [`kubectl`](https://kubernetes.io/docs/tasks/tools/). Start your LocalStack container using your preferred method. diff --git a/src/content/docs/aws/services/elasticache.mdx b/src/content/docs/aws/services/elasticache.mdx index 59aa10eb..eb386356 100644 --- a/src/content/docs/aws/services/elasticache.mdx +++ b/src/content/docs/aws/services/elasticache.mdx @@ -22,7 +22,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to ElastiCache and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to ElastiCache and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. ### Single cache cluster diff --git a/src/content/docs/aws/services/elasticbeanstalk.mdx b/src/content/docs/aws/services/elasticbeanstalk.mdx index 56b6bc23..dfad93f1 100644 --- a/src/content/docs/aws/services/elasticbeanstalk.mdx +++ b/src/content/docs/aws/services/elasticbeanstalk.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Elastic Beanstalk and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Elastic Beanstalk and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an Elastic Beanstalk application and environment with the AWS CLI. diff --git a/src/content/docs/aws/services/elb.mdx b/src/content/docs/aws/services/elb.mdx index a3bd2a13..ca63a647 100644 --- a/src/content/docs/aws/services/elb.mdx +++ b/src/content/docs/aws/services/elb.mdx @@ -17,7 +17,7 @@ The supported APIs are available on the API coverage section for [ELBv1](#api-co ## Getting started -This guide is designed for users new to Elastic Load Balancing and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Elastic Load Balancing and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an Application Load Balancer, along with its target group, listener, and rule, and forward requests to an IP target. diff --git a/src/content/docs/aws/services/emr.mdx b/src/content/docs/aws/services/emr.mdx index 9f8d6697..4b661617 100644 --- a/src/content/docs/aws/services/emr.mdx +++ b/src/content/docs/aws/services/emr.mdx @@ -26,7 +26,7 @@ Alternatively, you can use one of our `*-bigdata` Docker image tags which alread ## Getting started -This guide is designed for users new to EMR and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to EMR and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will create a virtual EMR cluster using the AWS CLI. diff --git a/src/content/docs/aws/services/es.mdx b/src/content/docs/aws/services/es.mdx index 7349ca43..936c7643 100644 --- a/src/content/docs/aws/services/es.mdx +++ b/src/content/docs/aws/services/es.mdx @@ -14,7 +14,7 @@ Any cluster created with the Elasticsearch Service will show up in the OpenSearc ## Creating an Elasticsearch cluster -You can go ahead and use [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) to create a new elasticsearch domain via the `lstk aws es create-elasticsearch-domain` command. +You can go ahead and use [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) to create a new elasticsearch domain via the `lstk aws es create-elasticsearch-domain` command. :::note Unless you use the Elasticsearch default version, the first time you create a cluster with a specific version, the Elasticsearch binary is downloaded, which may take a while to download. diff --git a/src/content/docs/aws/services/events.mdx b/src/content/docs/aws/services/events.mdx index b7b3f07e..805d0041 100644 --- a/src/content/docs/aws/services/events.mdx +++ b/src/content/docs/aws/services/events.mdx @@ -26,7 +26,7 @@ Any value for this variable now points to an invalid provider configuration and ## Getting Started -This guide is designed for users new to EventBridge and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to EventBridge and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate creating an EventBridge rule to run a Lambda function when a custom event is published to an event bus. diff --git a/src/content/docs/aws/services/firehose.mdx b/src/content/docs/aws/services/firehose.mdx index ebc7c40b..94c405a0 100644 --- a/src/content/docs/aws/services/firehose.mdx +++ b/src/content/docs/aws/services/firehose.mdx @@ -20,7 +20,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Data Firehose and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Data Firehose and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to use Firehose to load Kinesis data into Elasticsearch with S3 Backup with the AWS CLI. diff --git a/src/content/docs/aws/services/fis.mdx b/src/content/docs/aws/services/fis.mdx index 0b074746..cc29b7f2 100644 --- a/src/content/docs/aws/services/fis.mdx +++ b/src/content/docs/aws/services/fis.mdx @@ -43,7 +43,7 @@ Some of these events can automatically be undone after a defined time, such as s ## Getting started -This guide is designed for users new to FIS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to FIS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an experiment that stops EC2 instances. diff --git a/src/content/docs/aws/services/glacier.mdx b/src/content/docs/aws/services/glacier.mdx index ef7e615f..32a817ed 100644 --- a/src/content/docs/aws/services/glacier.mdx +++ b/src/content/docs/aws/services/glacier.mdx @@ -21,7 +21,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Glacier and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Glacier and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a vault, upload an archive, initiate a job to get an inventory details or download an archive, and delete the archive and vault with the AWS CLI. diff --git a/src/content/docs/aws/services/glue.mdx b/src/content/docs/aws/services/glue.mdx index 81c123c5..ad87e920 100644 --- a/src/content/docs/aws/services/glue.mdx +++ b/src/content/docs/aws/services/glue.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Glue and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Glue and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create databases and table metadata in Glue, run Glue ETL jobs, import databases from Athena, and run Glue Crawlers with the AWS CLI. diff --git a/src/content/docs/aws/services/iam.mdx b/src/content/docs/aws/services/iam.mdx index babd757f..08a9b361 100644 --- a/src/content/docs/aws/services/iam.mdx +++ b/src/content/docs/aws/services/iam.mdx @@ -19,7 +19,7 @@ The policy coverage is documented in the [IAM coverage documentation](/aws/devel ## Getting started -This guide is designed for users new to IAM and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to IAM and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can create a new user named `test`, create an access key pair for the user, and assert that the user is recognized after the access keys are configured in the environment. diff --git a/src/content/docs/aws/services/identitystore.mdx b/src/content/docs/aws/services/identitystore.mdx index 1e4a0cdf..b2354ee6 100644 --- a/src/content/docs/aws/services/identitystore.mdx +++ b/src/content/docs/aws/services/identitystore.mdx @@ -16,7 +16,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is aimed at users who are familiar with the AWS CLI and [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is aimed at users who are familiar with the AWS CLI and [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. It will walk you through the basics of setting up and managing groups within the AWS Identity Store using LocalStack. Start your LocalStack container using your preferred method. diff --git a/src/content/docs/aws/services/iot-data.mdx b/src/content/docs/aws/services/iot-data.mdx index ef73911b..b0eb0e18 100644 --- a/src/content/docs/aws/services/iot-data.mdx +++ b/src/content/docs/aws/services/iot-data.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to IoT Data and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to IoT Data and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a thing, update its shadow, get its shadow, and delete its shadow using IoT Data. diff --git a/src/content/docs/aws/services/iot.mdx b/src/content/docs/aws/services/iot.mdx index 6ae2b0e6..69e9577d 100644 --- a/src/content/docs/aws/services/iot.mdx +++ b/src/content/docs/aws/services/iot.mdx @@ -19,7 +19,7 @@ LocalStack ships a [Message Queuing Telemetry Transport (MQTT)](https://mqtt.org ## Getting Started -This guide is for users that are new to IoT and assumes a basic knowledge of the AWS CLI and LocalStack [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is for users that are new to IoT and assumes a basic knowledge of the AWS CLI and LocalStack [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start LocalStack using your preferred method. diff --git a/src/content/docs/aws/services/iotwireless.mdx b/src/content/docs/aws/services/iotwireless.mdx index bf24dbf5..5a6aaaf5 100644 --- a/src/content/docs/aws/services/iotwireless.mdx +++ b/src/content/docs/aws/services/iotwireless.mdx @@ -16,7 +16,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to IoT Wireless and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to IoT Wireless and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to use IoT Wireless to create wireless devices and gateways with the AWS CLI. diff --git a/src/content/docs/aws/services/kafka.mdx b/src/content/docs/aws/services/kafka.mdx index 5e154d48..4f8bc4d3 100644 --- a/src/content/docs/aws/services/kafka.mdx +++ b/src/content/docs/aws/services/kafka.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Managed Streaming for Kafka and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Managed Streaming for Kafka and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to configure an MSK Cluster locally, create a Kafka topic, and produce and consume messages. diff --git a/src/content/docs/aws/services/kinesis.mdx b/src/content/docs/aws/services/kinesis.mdx index 56843db4..0afb320d 100644 --- a/src/content/docs/aws/services/kinesis.mdx +++ b/src/content/docs/aws/services/kinesis.mdx @@ -19,7 +19,7 @@ Emulation for Kinesis is powered by [Kinesis Mock](https://github.com/etspaceman ## Getting started -This guide is designed for users new to Kinesis Data Streams and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Kinesis Data Streams and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a Lambda function to consume events from a Kinesis stream with the AWS CLI. diff --git a/src/content/docs/aws/services/kms.mdx b/src/content/docs/aws/services/kms.mdx index 36217fc5..4e8f799e 100644 --- a/src/content/docs/aws/services/kms.mdx +++ b/src/content/docs/aws/services/kms.mdx @@ -19,7 +19,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to KMS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to KMS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a simple symmetric encryption key and use it to encrypt/decrypt data. diff --git a/src/content/docs/aws/services/lakeformation.mdx b/src/content/docs/aws/services/lakeformation.mdx index 732fcf69..a3ed2274 100644 --- a/src/content/docs/aws/services/lakeformation.mdx +++ b/src/content/docs/aws/services/lakeformation.mdx @@ -16,7 +16,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Lake Formation and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Lake Formation and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to register an S3 bucket as a resource in Lake Formation, grant permissions to a user, and list the resources and permissions. diff --git a/src/content/docs/aws/services/lambda.mdx b/src/content/docs/aws/services/lambda.mdx index d33b886e..54f67d6d 100644 --- a/src/content/docs/aws/services/lambda.mdx +++ b/src/content/docs/aws/services/lambda.mdx @@ -20,7 +20,7 @@ The supported APIs are available on our [API coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Lambda and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Lambda and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a Lambda function with a Function URL. diff --git a/src/content/docs/aws/services/managedblockchain.mdx b/src/content/docs/aws/services/managedblockchain.mdx index e39d5acd..0632b29b 100644 --- a/src/content/docs/aws/services/managedblockchain.mdx +++ b/src/content/docs/aws/services/managedblockchain.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to AMB and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to AMB and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a blockchain network, a node, and a proposal. diff --git a/src/content/docs/aws/services/mediaconvert.mdx b/src/content/docs/aws/services/mediaconvert.mdx index 3d103e3e..b1b9839f 100644 --- a/src/content/docs/aws/services/mediaconvert.mdx +++ b/src/content/docs/aws/services/mediaconvert.mdx @@ -20,7 +20,7 @@ Elemental MediaConvert is in a preview state. ## Getting started -This guide is designed for users new to Elemental MediaConvert and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Elemental MediaConvert and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a MediaConvert job, list jobs, create a queue, and list all queues using the AWS CLI. diff --git a/src/content/docs/aws/services/memorydb.mdx b/src/content/docs/aws/services/memorydb.mdx index 0f6543de..62491002 100644 --- a/src/content/docs/aws/services/memorydb.mdx +++ b/src/content/docs/aws/services/memorydb.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to MemoryDB and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to MemoryDB and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can create a MemoryDB cluster and connect to it. diff --git a/src/content/docs/aws/services/mq.mdx b/src/content/docs/aws/services/mq.mdx index d0b188ed..4b4fa231 100644 --- a/src/content/docs/aws/services/mq.mdx +++ b/src/content/docs/aws/services/mq.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to MQ and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to MQ and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an MQ broker and send a message to a sample queue. diff --git a/src/content/docs/aws/services/mwaa.mdx b/src/content/docs/aws/services/mwaa.mdx index 9d63a482..7e09ccdf 100644 --- a/src/content/docs/aws/services/mwaa.mdx +++ b/src/content/docs/aws/services/mwaa.mdx @@ -16,7 +16,7 @@ The supported APIs are available on the [API Coverage section](#api-coverage). ## Getting started -This guide is designed for users new to MWAA and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to MWAA and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an Airflow environment and access the Airflow UI. diff --git a/src/content/docs/aws/services/neptune.mdx b/src/content/docs/aws/services/neptune.mdx index 97b50da0..58c66525 100644 --- a/src/content/docs/aws/services/neptune.mdx +++ b/src/content/docs/aws/services/neptune.mdx @@ -38,7 +38,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Neptune and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Neptune and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate the following with AWS CLI & Python: diff --git a/src/content/docs/aws/services/opensearch.mdx b/src/content/docs/aws/services/opensearch.mdx index f311aa7a..8542c442 100644 --- a/src/content/docs/aws/services/opensearch.mdx +++ b/src/content/docs/aws/services/opensearch.mdx @@ -40,7 +40,7 @@ You can select an Elasticsearch version with the `--engine-version` parameter wh ## Getting started -This guide is designed for users new to OpenSearch Service and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to OpenSearch Service and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a new OpenSearch Service cluster and interact with it, using the AWS CLI. diff --git a/src/content/docs/aws/services/organizations.mdx b/src/content/docs/aws/services/organizations.mdx index 07b5b1b1..06c6611c 100644 --- a/src/content/docs/aws/services/organizations.mdx +++ b/src/content/docs/aws/services/organizations.mdx @@ -17,7 +17,7 @@ Organizations is available over LocalStack for AWS and the supported APIs are av ## Getting started In this getting started guide, you'll learn how to create your local AWS Organization and configure it with member accounts. -This guide is intended for users who wish to get more acquainted with Organizations, and assumes you have basic knowledge of the AWS CLI (and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command). +This guide is intended for users who wish to get more acquainted with Organizations, and assumes you have basic knowledge of the AWS CLI (and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command). To get started, start your LocalStack instance using your preferred method: 1. Create a new local AWS Organization with the feature set flag set to `ALL`: diff --git a/src/content/docs/aws/services/pinpoint.mdx b/src/content/docs/aws/services/pinpoint.mdx index fd3d93dc..9364364e 100644 --- a/src/content/docs/aws/services/pinpoint.mdx +++ b/src/content/docs/aws/services/pinpoint.mdx @@ -22,7 +22,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Pinpoint and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Pinpoint and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a Pinpoint application, retrieve all applications, and list tags for the resource. diff --git a/src/content/docs/aws/services/pipes.mdx b/src/content/docs/aws/services/pipes.mdx index acb565a6..85c6b186 100644 --- a/src/content/docs/aws/services/pipes.mdx +++ b/src/content/docs/aws/services/pipes.mdx @@ -26,7 +26,7 @@ If you would like support for more APIs or report bugs, please make a request on ## Getting started -This guide is designed for users new to EventBridge Pipes and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to EventBridge Pipes and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a Pipe with SQS queues as source and target, and send events to the source queue which will be routed to the target queue. diff --git a/src/content/docs/aws/services/rds.mdx b/src/content/docs/aws/services/rds.mdx index 6e954376..2910a683 100644 --- a/src/content/docs/aws/services/rds.mdx +++ b/src/content/docs/aws/services/rds.mdx @@ -26,7 +26,7 @@ Recreating the RDS state is recommended for compatibility. ## Getting started -This guide is designed for users new to RDS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to RDS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate the following with the AWS CLI: diff --git a/src/content/docs/aws/services/redshift.mdx b/src/content/docs/aws/services/redshift.mdx index eeb73a25..40adc4d2 100644 --- a/src/content/docs/aws/services/redshift.mdx +++ b/src/content/docs/aws/services/redshift.mdx @@ -21,7 +21,7 @@ For advanced features like Redshift Data API and other emulation capabilities, p ## Getting started -This guide is designed for users new to RedShift and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to RedShift and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a RedShift cluster and database while using a Glue Crawler to populate the metadata store with the schema of the RedShift database tables using the AWS CLI. diff --git a/src/content/docs/aws/services/resource-groups-tagging-api.mdx b/src/content/docs/aws/services/resource-groups-tagging-api.mdx index 039744e2..b9ac1de1 100644 --- a/src/content/docs/aws/services/resource-groups-tagging-api.mdx +++ b/src/content/docs/aws/services/resource-groups-tagging-api.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Resource Groups Tagging API and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Resource Groups Tagging API and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create resources, tag them, and query them using the Resource Groups Tagging API. diff --git a/src/content/docs/aws/services/resource-groups.mdx b/src/content/docs/aws/services/resource-groups.mdx index bcf30d70..f19068c4 100644 --- a/src/content/docs/aws/services/resource-groups.mdx +++ b/src/content/docs/aws/services/resource-groups.mdx @@ -20,7 +20,7 @@ For tag-centric operations across AWS resources, see the [Resource Groups Taggin ## Getting Started -This guide is designed for users new to Resource Groups and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Resource Groups and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a Resource Group using the AWS CLI. diff --git a/src/content/docs/aws/services/route53.mdx b/src/content/docs/aws/services/route53.mdx index 64bbde4d..b9c9f04e 100644 --- a/src/content/docs/aws/services/route53.mdx +++ b/src/content/docs/aws/services/route53.mdx @@ -36,7 +36,7 @@ See [System DNS configuration](/aws/customization/networking/dns-server#system-d ## Getting started -This guide is designed for users new to Route53 and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Route53 and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a hosted zone and query the DNS record with the AWS CLI. diff --git a/src/content/docs/aws/services/route53resolver.mdx b/src/content/docs/aws/services/route53resolver.mdx index c03717e5..9badb7f6 100644 --- a/src/content/docs/aws/services/route53resolver.mdx +++ b/src/content/docs/aws/services/route53resolver.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Route53 Resolver and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Route53 Resolver and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a resolver endpoint, list the endpoints, and delete the endpoint with the AWS CLI. diff --git a/src/content/docs/aws/services/s3.mdx b/src/content/docs/aws/services/s3.mdx index 9259b60a..83fb03d8 100644 --- a/src/content/docs/aws/services/s3.mdx +++ b/src/content/docs/aws/services/s3.mdx @@ -19,7 +19,7 @@ The supported APIs are available on the API coverage section for [S3](#api-cover ## Getting started -This guide is designed for users new to S3 and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to S3 and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can create an S3 bucket, manage S3 objects, and generate pre-signed URLs for S3 objects. diff --git a/src/content/docs/aws/services/s3tables.mdx b/src/content/docs/aws/services/s3tables.mdx index 34bb6874..5f663804 100644 --- a/src/content/docs/aws/services/s3tables.mdx +++ b/src/content/docs/aws/services/s3tables.mdx @@ -18,7 +18,7 @@ The supported APIs are available on the [API coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to S3 Tables and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to S3 Tables and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a table bucket, a namespace, a table, and how to retrieve table details and metadata location with the AWS CLI. diff --git a/src/content/docs/aws/services/scheduler.mdx b/src/content/docs/aws/services/scheduler.mdx index fc3557f7..da3a03a0 100644 --- a/src/content/docs/aws/services/scheduler.mdx +++ b/src/content/docs/aws/services/scheduler.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to EventBridge Scheduler and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to EventBridge Scheduler and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can create a new schedule, list all schedules, and tag a schedule using the EventBridge Scheduler APIs. diff --git a/src/content/docs/aws/services/secretsmanager.mdx b/src/content/docs/aws/services/secretsmanager.mdx index 73458e30..454a58c3 100644 --- a/src/content/docs/aws/services/secretsmanager.mdx +++ b/src/content/docs/aws/services/secretsmanager.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Secrets Manager and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Secrets Manager and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a secret, get the secret value, and rotate the secret using the AWS CLI. diff --git a/src/content/docs/aws/services/serverlessrepo.mdx b/src/content/docs/aws/services/serverlessrepo.mdx index 003bdc58..d3143d45 100644 --- a/src/content/docs/aws/services/serverlessrepo.mdx +++ b/src/content/docs/aws/services/serverlessrepo.mdx @@ -72,7 +72,7 @@ Resources: ### Retrieve the Application ID -To retrieve the Application ID for your SAM application, you can utilize [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) by running the following command: +To retrieve the Application ID for your SAM application, you can utilize [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) by running the following command: ```bash lstk aws serverlessrepo list-applications diff --git a/src/content/docs/aws/services/servicediscovery.mdx b/src/content/docs/aws/services/servicediscovery.mdx index a9239265..b7b668b4 100644 --- a/src/content/docs/aws/services/servicediscovery.mdx +++ b/src/content/docs/aws/services/servicediscovery.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting Started -This guide is designed for users new to Service Discovery and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Service Discovery and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an ECS service containing a Fargate task that uses Service Discovery with the AWS CLI. diff --git a/src/content/docs/aws/services/ses.mdx b/src/content/docs/aws/services/ses.mdx index 55bfc2eb..157493b0 100644 --- a/src/content/docs/aws/services/ses.mdx +++ b/src/content/docs/aws/services/ses.mdx @@ -21,7 +21,7 @@ For advanced features like SMTP integration and other emulation capabilities, pl ## Getting Started This is an introductory guide to get started with SES. -Basic knowledge of the AWS CLI and LocalStack [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command is assumed. +Basic knowledge of the AWS CLI and LocalStack [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command is assumed. Start LocalStack using your preferred method. diff --git a/src/content/docs/aws/services/shield.mdx b/src/content/docs/aws/services/shield.mdx index f8520081..628ddfd1 100644 --- a/src/content/docs/aws/services/shield.mdx +++ b/src/content/docs/aws/services/shield.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting Started -This guide is designed for users new to Shield and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Shield and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a Shield protection, list all protections, and delete a protection with the AWS CLI. diff --git a/src/content/docs/aws/services/sns.mdx b/src/content/docs/aws/services/sns.mdx index bf87da7d..b3e48e73 100644 --- a/src/content/docs/aws/services/sns.mdx +++ b/src/content/docs/aws/services/sns.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started This guide is intended for users who wish to get more acquainted with SNS over LocalStack. -It assumes you have basic knowledge of the AWS CLI (and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command). +It assumes you have basic knowledge of the AWS CLI (and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command). Start your LocalStack container using your preferred method. We will demonstrate how to create an SNS topic, publish messages, and subscribe to the topic. diff --git a/src/content/docs/aws/services/sqs.mdx b/src/content/docs/aws/services/sqs.mdx index ee2050ea..5483aa9d 100644 --- a/src/content/docs/aws/services/sqs.mdx +++ b/src/content/docs/aws/services/sqs.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to SQS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to SQS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create an SQS queue, retrieve queue attributes and URLs, and receive and delete messages from the queue. diff --git a/src/content/docs/aws/services/ssm.mdx b/src/content/docs/aws/services/ssm.mdx index b01ebf66..1abfebe8 100644 --- a/src/content/docs/aws/services/ssm.mdx +++ b/src/content/docs/aws/services/ssm.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Systems Manager (SSM) and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Systems Manager (SSM) and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method with an additional `EC2_VM_MANAGER=docker` configuration variable. We will demonstrate how to use EC2 and SSM functionalities when using the Docker backend with LocalStack with the AWS CLI. diff --git a/src/content/docs/aws/services/sso-admin.mdx b/src/content/docs/aws/services/sso-admin.mdx index e129ce9b..c1a5203c 100644 --- a/src/content/docs/aws/services/sso-admin.mdx +++ b/src/content/docs/aws/services/sso-admin.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to SSO Admin and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to SSO Admin and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a permission set, add tags to a permission set, and list permission sets. diff --git a/src/content/docs/aws/services/stepfunctions.mdx b/src/content/docs/aws/services/stepfunctions.mdx index b7a7b7ee..35efe3ca 100644 --- a/src/content/docs/aws/services/stepfunctions.mdx +++ b/src/content/docs/aws/services/stepfunctions.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Step Functions and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Step Functions and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can create a state machine, execute it, and check the status of the execution. diff --git a/src/content/docs/aws/services/sts.mdx b/src/content/docs/aws/services/sts.mdx index 52d1cf65..5ec0a659 100644 --- a/src/content/docs/aws/services/sts.mdx +++ b/src/content/docs/aws/services/sts.mdx @@ -18,7 +18,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to STS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to STS and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to assume an IAM Role and assume the role as well as creating an IAM user and getting using the STS with the AWS CLI. diff --git a/src/content/docs/aws/services/support.mdx b/src/content/docs/aws/services/support.mdx index dfc9bf7c..cdbd40fa 100644 --- a/src/content/docs/aws/services/support.mdx +++ b/src/content/docs/aws/services/support.mdx @@ -24,7 +24,7 @@ It's important to note that LocalStack doesn't offer a programmatic interface to ## Getting started -This guide is designed for users new to Support and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Support and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can create a case in the mock Support Center using the AWS CLI. diff --git a/src/content/docs/aws/services/swf.mdx b/src/content/docs/aws/services/swf.mdx index d0c5f8ce..9363aae5 100644 --- a/src/content/docs/aws/services/swf.mdx +++ b/src/content/docs/aws/services/swf.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Simple Workflow Service and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Simple Workflow Service and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to register an SWF domain and workflow using the AWS CLI. diff --git a/src/content/docs/aws/services/textract.mdx b/src/content/docs/aws/services/textract.mdx index 2fd6f728..5606db18 100644 --- a/src/content/docs/aws/services/textract.mdx +++ b/src/content/docs/aws/services/textract.mdx @@ -15,7 +15,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), p ## Getting started -This guide is tailored for users new to Textract and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is tailored for users new to Textract and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to perform basic Textract operations, such as mocking text detection in a document. diff --git a/src/content/docs/aws/services/timestream-query.mdx b/src/content/docs/aws/services/timestream-query.mdx index dac86c40..92bef078 100644 --- a/src/content/docs/aws/services/timestream-query.mdx +++ b/src/content/docs/aws/services/timestream-query.mdx @@ -20,7 +20,7 @@ The supported APIs are available on our API Coverage Page ([Timestream Query](#a ## Getting Started -The following example illustrates the basic operations, using the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command line. +The following example illustrates the basic operations, using the [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command line. First, we create a test database and table: diff --git a/src/content/docs/aws/services/transcribe.mdx b/src/content/docs/aws/services/transcribe.mdx index 0da909d6..2a874516 100644 --- a/src/content/docs/aws/services/transcribe.mdx +++ b/src/content/docs/aws/services/transcribe.mdx @@ -22,7 +22,7 @@ Language models typically have a size of around 50 MiB and are saved in the cach ## Getting Started -This guide is designed for users new to Transcribe and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Transcribe and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a transcription job and view the transcript in an S3 bucket using the AWS CLI. diff --git a/src/content/docs/aws/services/verifiedpermissions.mdx b/src/content/docs/aws/services/verifiedpermissions.mdx index 3e27c72c..013dbcff 100644 --- a/src/content/docs/aws/services/verifiedpermissions.mdx +++ b/src/content/docs/aws/services/verifiedpermissions.mdx @@ -17,7 +17,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is designed for users new to Verified Permissions and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is designed for users new to Verified Permissions and assumes basic knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how to create a Verified Permissions Policy Store, add a policy to it, and authorize a request with the AWS CLI. diff --git a/src/content/docs/aws/services/waf.mdx b/src/content/docs/aws/services/waf.mdx index d3450311..fefa61b2 100644 --- a/src/content/docs/aws/services/waf.mdx +++ b/src/content/docs/aws/services/waf.mdx @@ -16,7 +16,7 @@ The supported APIs are available on our [API Coverage section](#api-coverage), w ## Getting started -This guide is for users who are familiar with the AWS CLI and [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +This guide is for users who are familiar with the AWS CLI and [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will walk you through creating, listing, tagging, and viewing tags for Web Access Control Lists (WebACLs) using the Web Application Firewall (WAF) service in a LocalStack environment using the AWS CLI. diff --git a/src/content/docs/aws/services/xray.mdx b/src/content/docs/aws/services/xray.mdx index 4313bb83..dccdf83c 100644 --- a/src/content/docs/aws/services/xray.mdx +++ b/src/content/docs/aws/services/xray.mdx @@ -28,7 +28,7 @@ which provides information on the extent of X-Ray integration with LocalStack. ## Getting started This guide is designed for users new to X-Ray and assumes basic -knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/#aws) command. +knowledge of the AWS CLI and our [`lstk aws`](/aws/developer-tools/running-localstack/lstk/aws-and-iac-commands/#aws) command. Start your LocalStack container using your preferred method. We will demonstrate how you can create a minimal [trace segment](https://docs.aws.amazon.com/xray/latest/devguide/xray-api-segmentdocuments.html#api-segmentdocuments-fields) 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 80e9e72c..8fd17102 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 @@ -71,7 +71,7 @@ on their official documentation page. #### LocalStack CLI -`lstk` takes container environment variables and bind mounts from its [`config.toml`](/aws/developer-tools/running-localstack/lstk/#configuration) +`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`: @@ -109,8 +109,8 @@ lstk start ``` This is the easiest way to quickly spin up the desired services at startup. -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 [`env` profile](/aws/developer-tools/running-localstack/lstk/configuration/#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/configuration/#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.