lstk Setup & Maintenance

`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. For the Azure emulator, that is setup azure.

lstk setup azure

`setup azure`

Prepare an isolated Azure CLI configuration directory (under the lstk config dir, via AZURE_CONFIG_DIR) that routes lstk az commands to the LocalStack Azure emulator. Your global ~/.azure configuration is left untouched.

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.

Registering 'LocalStack' custom cloud...
Logging in with dummy service-principal credentials...
✔︎ Azure CLI integration ready. Run 'lstk az <command>' to talk to LocalStack.

Run this once; afterwards use lstk az <args> to run Azure CLI commands against LocalStack. Running it again is safe: it updates the existing LocalStack cloud instead of registering a new one. To instead redirect your global az (so existing scripts run unmodified against LocalStack), see lstk az start-interception.

`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.

lstk config path

This subcommand is read-only: it never creates or initializes a config file. If --config <path> 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.

lstk update [options]

Option	Description
`--check`	Check for updates without installing them
`--force`	Replace the binary even when the install is managed by another tool or its directory looks unwritable
`--non-interactive`	Use plain output instead of the TUI (update logic unchanged)
`--json`	Emit the result as a JSON envelope (see Structured output). With `--check`, `data` reports `currentVersion`/`latestVersion`/`updateAvailable`; after an applied update, `updatedVersion`/`updated`/`method`.

Examples:

# 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, verifies its SHA-256 against the release’s checksums.txt (a missing, malformed, or mismatched checksum aborts the update), extracts it, and replaces the running executable in place.

An install managed by another tool (mise, nix, guix, asdf, scoop, or chocolatey), or one in a directory lstk cannot write to, is not updated in place: update it through that tool, or pass --force to replace the binary anyway.

With --check, lstk only reports whether a newer version is available and exits without downloading or installing anything:

Checking for updates...
> Note: Already up to date (1.2.0)

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. To turn this check off, set check_for_update_on_startup = false under [cli] in config.toml, or LSTK_CHECK_FOR_UPDATE_ON_STARTUP=false in the environment, which wins over the config key.

In an interactive terminal, when an update is available, lstk prints the new version and a release-notes link, and then prompts:

Update lstk to latest version?
> Update now [U]
  Remind me next time [R]
  Never check again [N]

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.
Never check again [N]: writes check_for_update_on_startup = false under [cli] in config.toml, so later starts skip the check. lstk only offers this option when a config.toml file exists.

In non-interactive mode, the notification is not a prompt: lstk prints a single note and continues.

> Note: Update available: 1.1.0 → v1.2.0 (run lstk update)

For an install managed by another tool, the note names that tool instead of lstk update.

Offline and enterprise environments

There is no --offline flag. Instead, lstk degrades gracefully when common enterprise blockers, such as an unreachable Docker Hub or a proxy, prevent an internet request:

Image pull: if the image pull fails but the image is already present locally, lstk prints a note (Could not pull <image> (<error>); using the local image) and starts the local image instead of failing. With a pinned tag other than latest, lstk doesn’t pull at all when the image is already present, and prints Using local image <image>. In interactive mode, you can also press Esc to abort an in-progress pull and fall back to the local image.
License check: lstk doesn’t run its pre-flight license check for the Azure emulator. The emulator validates the license itself when it starts and caches it in its volume. Later starts try the cached license first, and contact the license server only when the cached license can’t be used.
Telemetry and update checks are best-effort and fail silently when offline.

Pair this behavior with a custom image that points at an internal-registry mirror or a locally loaded image when Docker Hub isn’t reachable.

Was this page helpful?