StreamSnow is a free, open-source (MIT) Claude Code plugin and Python CLI for building Streamlit in Snowflake apps with an AI coding agent. It was built and tested heavily in a production BI setting.

A coding agent can write a Streamlit app in minutes. The harder part is trusting what it wrote: which tables it reads, whether the numbers are right, and who deployed it. StreamSnow gives the agent a governed GitHub repository to work in. The repo holds the rules the agent reads, checks that run before anything merges, a runnable SQL file behind every metric, and a deploy that only GitHub Actions can run.

In this guide you install StreamSnow, connect it to your Snowflake account, build a sales dashboard on the TPC-H sample data, check one of its numbers against your own SQL, and ship it to Snowflake through a pull request.

To watch the whole flow first, see the StreamSnow walkthrough on YouTube.

Create a folder for your apps and make it a Git repository with a matching private GitHub repository:

Install the plugin at project scope. Both commands record it in the repository's .claude/settings.json, so teammates who clone the repo are offered the same plugin:

You can also open Claude Code in the folder and paste this prompt, which runs the same steps and asks before installing anything:

The dashboard in this guide reads the TPC-H sample database. If your account has no SNOWFLAKE_SAMPLE_DATA database, create it in Snowsight:

Open Claude Code in the folder and run:

If /onboard isn't listed, run /reload-plugins first. Onboarding works in four stages and explains each step before it takes it.

1. Check and prepare. It installs the streamsnow CLI, runs streamsnow doctor, and lists the Snowflake access you already have, such as a snow connection. It reads your account with read-only SHOW queries to suggest answers, then installs any missing tools after one approval.
2. One round of questions. Each question comes with an explanation and a recommended answer. For this guide:
   • Snowflake connection: let onboarding set up your local snow connection, or guide you through it. You approve the sign-in in your browser.
   • Runtime: container (or warehouse on a trial account).
   • Sources apps may read: pick SNOWFLAKE_SAMPLE_DATA.TPCH_SF1. In your own account, this is where you limit apps to curated reporting schemas.
   • App data schema: keep the recommendation.
   • Schemas apps may not query: keep the raw and working layers on the deny list.
   • Deploy source: stage copy. GitHub Actions uploads the app code to an internal stage. The Snowflake Git repository option also works but needs an API integration and, for a private repository, a GitHub token.
   • Who runs the admin script: you, if you are the admin.
   • Viewer access: the Snowflake roles that should open the apps.
   • Remaining defaults: onboarding lists the names it will use for the app database, warehouse, roles and integrations. Keep them to follow this guide.
3. Build. After you confirm, it writes streamsnow.config.yaml and the governed repository files: AGENTS.md, CLAUDE.md, pre-commit hooks, CI and deploy workflows, and a README.
4. Finish. It creates the CI key pair, writes the admin script to .internal/admin-setup.sql, and, once the script has run, stores the deploy secrets in GitHub.

When onboarding has committed the governed files, push them so GitHub has a main branch for pull requests:

streamsnow.config.yaml is now the single source of truth for your setup. It names the app database, warehouse, roles, allowed sources and deny list, and it holds no secrets. Every check, the CI pipeline and the agent read it.

Onboarding stops once for the admin script. It copies .internal/admin-setup.sql to your clipboard. In Snowsight, open a new SQL worksheet, paste the script, choose Run All, and tell Claude it ran. Claude never runs the admin script itself.

The script is commented section by section. With the default names, it creates:

If someone else is your admin, onboarding writes a short note naming the file for you to forward. You can build and preview while you wait. Only deploys need the script.

The CI key never passes through Claude. streamsnow ci-key create makes the key pair on your machine. The public half goes into the admin script, and streamsnow ci-key push hands the private half to a GitHub secret through the GitHub CLI. The plugin also blocks Claude's tools from opening the key folder.

Save a copy of ~/.streamsnow-ci/streamsnow_ci_rsa_key.p8 in your password manager. If it is lost, make a new pair and run the admin script again.

Before it stores the secrets, onboarding offers to run streamsnow ci-key verify, which signs in from your machine as the CI user the way the deploy job does. At the end it offers to turn on GitHub's setting that deletes branches once their pull requests merge.

Describe the dashboard you want:

/build-app starts with the spec. It asks a few questions about the data, each with a recommended answer and the reason for it.

In the walkthrough the answers were: order date as the revenue date, all line items included, the top 10 part types, and an 1800-second cache, so the app re-queries Snowflake at most every 30 minutes.

Checkpoint 1 asks you to approve the spec, saved as REQUIREMENTS.md, before any code is written:

Then a subagent profiles the data and another plans every page. Checkpoint 1b shows a text wireframe for your approval. If you are unsure about a design choice, approve it here. You can change anything at the preview.

After that, /build-app scaffolds the app and runs one builder subagent per page in parallel, followed by reviewers. This is the longest stage, about half an hour in the walkthrough, and it needs nothing from you.

The app lands in apps/<slug>/:

Every app also gets an About this app page, built from the app itself: purpose, metric definitions and data sources. The documentation lives inside the dashboard, so it stays current as the agent changes the app.

/build-app pauses at Checkpoint 2 with the app running locally against live Snowflake, at http://localhost:8501. This is your click-through.

Click through every page as your stakeholders would. Then send feedback in plain words:

StreamSnow sorts the feedback, builds the changes the same governed way with one commit per fix, and brings you back to the preview.

/validate-app is the gate every app must pass before it ships: a pass or fail check of required files, schema references against your allowed sources and deny list, security, caching and the SQL review files. /review-app <slug> --auto is advisory: a senior-style review by reviewers for SQL, data, UI, runtime and docs, which applies fixes and repeats until no new mechanical findings remain.

Brand settings you ask for, such as theme colors and fonts, go into streamsnow.config.yaml, so every future app in the repository starts with them.

Every page has a runnable SQL file in apps/<slug>/sql_review/, with one section per metric in on-screen order. Open 01_overview.sql in Snowsight or any SQL editor and run the revenue section. It should return the number on the Overview page.

You can also check the headline numbers with your own query:

For 1997 you should see 227,783 orders and revenue of about $33.05 billion, an average order value of $145,092. Against 1996 ($33.28 billion), revenue fell 0.69 percent, the same change the dashboard shows. If your dashboard used different spec answers, such as ship date instead of order date, your numbers will differ by the same rule.

When a number doesn't match, the sql_review file shows exactly which tables, filters and joins the app used. For a deeper check, /sql-review <slug> runs every section against live Snowflake as aggregates and writes a review log for a person to sign. Skip it when a change touches no metrics.

When you are happy with the preview, run this. It is Checkpoint 3, and only you start it:

/ship-app runs the validation again, offers to review any changes made since the last review, opens a pull request and gives you the app link.

The pull request runs the same checks in GitHub Actions. When you merge it, the deploy workflow signs in as the CI user, uploads the app to the stage and creates the Streamlit app. Nothing else deploys.

The app appears in the Streamlit apps list in Snowsight, under STREAMSNOW_APPS.DASHBOARDS and owned by STREAMSNOW_DEPLOY_ROLE. streamsnow app-url sales-performance prints its Snowsight link.

To give a colleague access, grant them the viewer role. They sign in to Snowsight with their own Snowflake login and open the app.

Teammates who join later clone the repository, accept the plugin when Claude Code offers it, and run /onboard. It sees the existing setup and only prepares their machine.

StreamSnow fits metrics you know you want and many people will open the same way, the job a traditional BI dashboard does. A few limits come with that.

Compute cost. Apps use Snowflake credits: the warehouse for queries and, on the container runtime, the compute pool. SYSTEM_COMPUTE_POOL_CPU packs three apps per node, and a container app's server stops after three days without viewers. A longer cache means fewer queries, and a frequently refreshed app costs more. See Streamlit in Snowflake billing and compare it with the per-user licenses of your current BI tool.

Viewers need Snowflake logins. Apps are for people inside your organization who can sign in to Snowsight. Dashboards for people without Snowflake logins need customization beyond what StreamSnow sets up.

Queries run as the app's owner. Apps run with owner's rights: queries run as the deploy role that owns the app, not the viewer's role, and viewers need only usage on the app. Masking and row access policies on the underlying data need Enterprise Edition or higher. StreamSnow's own guardrails are static checks and work on any edition.

StreamSnow builds and governs apps. It does not schedule data pipelines or replace a data catalog.

StreamSnow prints a teardown script for the objects the admin script created. It never runs it for you:

Review every line, then run it in Snowsight as ACCOUNTADMIN. It drops the app database with every deployed app in it, the warehouse, the CI user, both roles and the PyPI integration, and it keeps your source databases and SYSTEM_COMPUTE_POOL_CPU. If any of those objects existed before StreamSnow and other work uses them, delete their lines first.

Then delete the local key folder and, if you made it only for this guide, the GitHub repository:

You set up a governed repository for Streamlit in Snowflake apps, connected GitHub Actions to Snowflake with a key-pair CI user, had Claude Code build a dashboard behind four human checkpoints, tied its revenue number back to SQL, and shipped it through a pull request. The same repository holds every future app your team builds, under the same rules.

StreamSnow is free and MIT licensed. Issues, discussions and pull requests are welcome in the repository.