DOC-339: Rewrite Snowflake Getting Started to mirror AWS v2 and default to lstk by quetzalliwrites · Pull Request #878 · localstack/localstack-docs

quetzalliwrites · 2026-08-20T11:33:31Z

Summary

Mirrors the AWS Getting Started rewrite (DOC-12, #606) information architecture for Snowflake: Overview, Installation, Local Development, CI Integration, AI & Agent Workflows, Auth Token, FAQ.

Overview and Installation are split into separate pages (previously combined into one file titled "Installation" with no landing page). Overview is a new SectionCards landing page; Installation leads with lstk (lstk start --type snowflake), with Docker Compose/CLI as secondary paths.
Quickstart is decoupled and removed. Its content is folded into a new Local Development page with an explicit, unbroken walkthrough: start the emulator via lstk → connect the Snowflake CLI to a localstack connection profile → run a first query → inspect results in the Web App → clean up. Adds a 301 redirect from the old quickstart URL.
CI Integration is a new page with lstk-based CI snippets.
AI & Agent Workflows is a new top-level page centered on the MCP server's localstack-snowflake-client tool.
Auth Token and FAQ are restructured to match the AWS pattern while keeping Snowflake-specific content (session verify endpoint, SQL API/hostname/image-tag FAQs) that has no AWS equivalent.
Fixed three tutorial pages whose prerequisite links pointed at the now-split /snowflake/getting-started/ page.

Where this deliberately doesn't mirror AWS 1:1

No lstk wrapper for the Snowflake CLI. Agents/users run snow directly against its own localstack connection profile — there's no lstk snow proxy the way there's lstk aws/lstk terraform/lstk cdk.
No per-provider CI guide fan-out. AWS links to dedicated /aws/ci-pipelines/<provider>/ pages; Snowflake only has one consolidated CI page, so CI Integration links there instead of inventing pages that don't exist.
No claim about Snowflake-specific LocalStack Skills coverage — couldn't verify one way or the other, so the AI & Agent Workflows page omits that bullet rather than guessing.
Did not reuse AWS's LocalStack/setup-localstack@main GitHub Action example for the CI snippets, since its Snowflake support is unverified; used a plain lstk-based step instead.

Linear: https://linear.app/localstack/issue/DOC-339/docs-snowflake-getting-started-v2-also-making-lstk-default-cli

Test plan

astro build completes successfully (403 pages)
starlight-links-validator reports all internal links valid
No "Quickstart" naming remains anywhere in the Snowflake Getting Started section
All CLI examples in the 7 nav pages use lstk
Nav titles/order verified: Overview(1), Installation(2), Local Development(3), CI Integration(4), AI & Agent Workflows(5), Auth Token(6), FAQ(7)

…lt to lstk Mirrors the AWS Getting Started rewrite (DOC-12) information architecture: Overview, Installation, Local Development, CI Integration, AI & Agent Workflows, Auth Token, FAQ. - Overview and Installation are split into separate pages; Overview is a new SectionCards landing page, Installation leads with lstk (lstk start --type snowflake), with Docker Compose/CLI as secondary paths. - Quickstart is decoupled and removed; its content is folded into a new Local Development page with an explicit, unbroken walkthrough: start the emulator via lstk, connect the Snowflake CLI to a `localstack` connection profile, run a first query, inspect results in the Web App, then clean up. Adds a redirect from the old quickstart URL. - CI Integration is a new page with lstk-based CI snippets, and AI & Agent Workflows is a new top-level page centered on the MCP server's localstack-snowflake-client tool. - Auth Token and FAQ are restructured to match the AWS pattern while keeping Snowflake-specific content (session verify endpoint, SQL API/hostname/image-tag FAQs) that has no AWS equivalent. - Fixed three tutorial pages whose prerequisite links pointed at the now-split /snowflake/getting-started/ page. Deviates from a literal AWS mirror where the underlying product differs: no lstk wrapper for the Snowflake CLI (agents run `snow` directly against its own connection profile), no per-provider CI guide fan-out (links to the existing consolidated CI integration page instead), and no claim about Snowflake-specific LocalStack Skills coverage since it could not be verified.

cloudflare-workers-and-pages · 2026-08-20T11:34:36Z

Deploying localstack-docs with Cloudflare Pages

Latest commit:	`3745f3c`
Status:	✅ Deploy successful!
Preview URL:	https://c42c795f.localstack-docs.pages.dev
Branch Preview URL:	https://doc-339-docs-snowflake-getti.localstack-docs.pages.dev

View logs

quetzalliwrites · 2026-08-20T11:35:42Z

Moving this to draft mode, still want to test and refine it further before going to review round.

Small wording tweaks across Overview, Installation, and AI & Agent Workflows for clarity and consistency.

remotesynth

Note that I did a read of the pages and they look good but I not get to run through the steps to confirm.

mmaureenliu

Thanks for the wonderful work! Mostly looks great to me, with some modifications suggested:

mainly use lstk start not lstk start --type snowflake
I want Peter and Przemek to review some tech content for accuracy
I assume the AI workflow works, but would appreciate acknowledgement from someone who's tested it (I don't have time to test it in the next few days)

mmaureenliu · 2026-08-26T13:46:34Z

 ## Prerequisites

- [`localstack` CLI](/snowflake/getting-started/) with a [`LOCALSTACK_AUTH_TOKEN`](/snowflake/getting-started/auth-token/)
+- [`localstack` CLI](/snowflake/getting-started/installation/) with a [`LOCALSTACK_AUTH_TOKEN`](/snowflake/getting-started/auth-token/)


The prereq should be lstk rather than localstack CLI and the starting emulator step needs to reference lstk as well - is that meant to be addressed in a separate PR (together with other lstk related snowflake docs update)?

mmaureenliu · 2026-08-26T13:50:07Z

+
+- **Accelerate data pipeline development**: Run dbt, Airflow, and Snowpark pipelines against a local Snowflake-compatible endpoint instead of waiting on cloud credits or shared environments.
+- **Automate integration testing**: Run SQL and data pipeline tests in CI against a local emulator, without touching a real Snowflake account.
+- **Validate SQL compatibility**: Check queries, UDFs, and stored procedures against LocalStack's Snowflake SQL support before deploying to production.


I think "against LocalStack before deploying to production" is sufficient. For the reader of this doc, "LocalStack" is the snowflake emulator and in this context we don't need to differentiate this from the AWS emulator.

mmaureenliu · 2026-08-26T13:54:43Z

+
+## lstk
+
+`lstk` is a lightweight CLI for LocalStack that manages the authentication and container lifecycle for the AWS, Snowflake, and Azure emulators in a single workflow.


I'd remove "for the AWS, Snowflake, and Azure emulators" part and keep it identical to the AWS doc. Like my comment in the overview section, given the docs context, readers understand this applies to Snowflake, and may not care about other emulators (or they can read about other emulators in their own docs). To me the current phrasing suggests that lstk supports a multi-emulator setup which unfortunately is not true yet.

mmaureenliu · 2026-08-26T13:58:27Z

+
+### Start the Snowflake emulator
+
+`lstk` starts the AWS emulator by default. Select the Snowflake emulator with `--type snowflake` on your first start; `lstk` records the choice in your `config.toml`, so subsequent `lstk start` calls reuse it:


In a fresh installation, lstk does NOT start the AWS emulator by default. Instead, it asks you which emulator you want to start and records it in its global config. For now I'd not recommend using the --type snowflake command at initial setup, as the team is still debating whether it should mutate the global config.

@peter-smith-phd can you comment on the --type flag here pls?

P.S. @quetzalliwrites here you can copy what we did for the Azure getting started guide: https://docs.localstack.cloud/azure/getting-started/

I think the --type snowflake option is acceptable in this case, because it's creating the config.toml for the first time. Although, using the interactive menu to select an emulator type might be a better way (if there's a human making the selection).

The concern with lstk start --type only arises when there's a pre-existing config.toml that will be modified, therefore harming the user's hand-crafted settings. The user will think "I'm just starting a one-time instance of Snowflake", but in fact they've now committed that every future instance will also be for Snowflake (with some AWS/Azure-specific settings that they hand-crafted).

My concern is more: if we change the behaviour of --type so it does not modify global config, what happens when your first ever run of lstk start is with --type snowflake? If an emulator type is not chosen, the default in config is indeed aws.

The goal would be to allow --type if there isn't a config.toml already, and just disallow it if config.toml already exists. In the medium-term future, we'll probably be moving to a single image that contains all the emulators, so --type will complete disappear anyway.

mmaureenliu · 2026-08-26T14:02:16Z

+
+## Container and orchestration tools
+
+Use these methods when you need explicit container configuration, want to run LocalStack alongside other services, or deploy LocalStack in CI environments.


We actually recommend using lstk for CI if user just needs to deploy a single LocalStack container. @peter-smith-phd what do you think? (I also notice the CI wording in AWS getting started guide)

Yes, as a general rule I'd recommend using lstk inside CI. The exception would be if CI is also running other containers that need to be carefully orchestrated alongside LocalStack.

mmaureenliu · 2026-08-26T15:24:25Z

+Create a connection profile that points the Snowflake CLI at your local emulator:
+
+```bash
+snow connection add \


This is (strong) personal preference, but I consider it best practice to recommend configuring test credentials to follow format of real credentials and also distinguishable from each other (if all values are test, connection troubleshooting can be tricky).

e.g. my test connection would be:
--user test_user --password TestPassword1! --account test-account

Having said that, I vaguely remember there's some limitation in the python emulator that my above config might not work (though they conform to real snowflake rules and work against the rust emulator) - @hovaesco do you want to comment?

mmaureenliu · 2026-08-26T15:33:09Z

+  </TabItem>
+</Tabs>
+
+`lstk start --non-interactive` blocks until the emulator reports healthy, or exits non-zero if it fails to start within the readiness deadline (60 seconds by default). This means no separate wait step is required, unlike CI setups based on the legacy `localstack` CLI's `localstack start -d && localstack wait -t 60` pattern. Override the deadline with `--timeout` or [`LSTK_STARTUP_TIMEOUT`](/aws/developer-tools/running-localstack/lstk/#environment-variables) if your runner needs more time to pull the image.


I'd remove "unlike CI setups based on the legacy localstack CLI's localstack start -d && localstack wait -t 60 pattern" - user doesn't need to care about a legacy method that they most likely never heard about.

mmaureenliu · 2026-08-26T15:40:46Z

I only skim read this one as I assume this to be largely the same as the aws version with just a few links changed (like getting a snowflake license)

mmaureenliu · 2026-08-26T15:41:15Z

@peter-smith-phd can you review this doc for accuracy please?

mmaureenliu · 2026-08-26T15:42:15Z


 ```bash
-DOCKER_FLAGS='-e SF_LOG=trace' DEBUG=1 localstack start --stack snowflake
+lstk start --type snowflake


should be lstk start

quetzalliwrites requested review from HarshCasper and remotesynth as code owners August 20, 2026 11:33

quetzalliwrites self-assigned this Aug 20, 2026

quetzalliwrites marked this pull request as draft August 20, 2026 11:35

DOC-339: Minor copy polish

3745f3c

Small wording tweaks across Overview, Installation, and AI & Agent Workflows for clarity and consistency.

quetzalliwrites marked this pull request as ready for review August 25, 2026 18:24

quetzalliwrites requested a review from mmaureenliu August 25, 2026 18:26

remotesynth approved these changes Aug 26, 2026

View reviewed changes

mmaureenliu requested changes Aug 26, 2026

View reviewed changes


		## lstk

		`lstk` is a lightweight CLI for LocalStack that manages the authentication and container lifecycle for the AWS, Snowflake, and Azure emulators in a single workflow.


		### Start the Snowflake emulator

		`lstk` starts the AWS emulator by default. Select the Snowflake emulator with `--type snowflake` on your first start; `lstk` records the choice in your `config.toml`, so subsequent `lstk start` calls reuse it:


		## Container and orchestration tools

		Use these methods when you need explicit container configuration, want to run LocalStack alongside other services, or deploy LocalStack in CI environments.

Uh oh!

Conversation

quetzalliwrites commented Aug 20, 2026

Summary

Where this deliberately doesn't mirror AWS 1:1

Test plan

Uh oh!

cloudflare-workers-and-pages Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying localstack-docs with Cloudflare Pages

Uh oh!

quetzalliwrites commented Aug 20, 2026

Uh oh!

remotesynth left a comment

Choose a reason for hiding this comment

Uh oh!

mmaureenliu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

cloudflare-workers-and-pages Bot commented Aug 20, 2026 •

edited

Loading