Snowflake App Runtime - Deploy Full-Stack Web Apps Right Next to Your Data from a Single Prompt

Introduction

Snowflake Summit 2026 brought a flood of new features. Among them, one that I'm especially keeping an eye on is Snowflake App Runtime.

Have you ever felt one of these frustrations?

• Your data is neatly organized inside Snowflake, but the web app that surfaces it runs somewhere else entirely
• To ship an app, you have to stand up Docker, infrastructure, and an auth layer every single time
• You just want to build an internal tool, but you end up copying data out to the app side, and governance goes out the window

Snowflake App Runtime answers exactly these pain points. In a nutshell, it lets you deploy a full-stack web app (Next.js and friends) right next to your data — inside Snowflake itself. No infrastructure to build, authentication handled for you, and no data movement.

On top of that, when you pair it with the AI coding agent CoCo (at Snowflake Summit 2026, Cortex Code was officially renamed CoCo, so I'll use CoCo throughout this article), you can go from a prompt to a scaffolded app and all the way to deployment.

This article walks through what Snowflake App Runtime is, the snowflake-apps skill bundled with CoCo, the basic workflow, and the things I noticed while actually building a sales dashboard — explained as plainly as I can.

App Runtime is a brand-new area, so I hope this article gives a helping hand to anyone who wants to try it out.

Note: (June 2026) Snowflake App Runtime and CoCo Desktop, as introduced in this article, include features that are in Public Preview. They may change significantly in future updates, so please keep that in mind.

Note: This article reflects my personal views and does not represent Snowflake's official position.

What is Snowflake App Runtime?

Snowflake App Runtime is a new platform for building and deploying full-stack web applications on Snowflake. The official documentation describes it like this:

Snowflake App Runtime lets you go from an idea to a live, deployed web application in minutes. No infrastructure to provision, no credentials to configure, no Docker expertise required.

Here's a summary of its characteristics:

Aspect	Details
Supported stack	During Public Preview, it builds Node.js apps (especially Next.js). Python support is also planned
Runtime	Runs as a dedicated APPLICATION SERVICE object on Snowpark Container Services (SPCS)
Authentication	Snowflake SSO is applied automatically — no auth code required
Data access	Directly queries data in the same Snowflake account. No data copies, no external API layer
Public URL	An authenticated URL in the form https://<id>-<org>-<account>-<region>.snowflakecomputing.app/ is issued automatically
Status	Public Preview (available to all accounts; trial accounts excluded)

Here's a point that's easy to trip over. When you hear "runs on SPCS," you might picture the SPCS services you know — the ones where you build a container yourself and run CREATE SERVICE. But App Runtime uses a different object type, APPLICATION SERVICE. The big difference is that instead of writing a service specification (spec) file yourself, it deploys from a versioned package.

The official docs spell this out:

Unlike a Snowpark Container Services service, an Application Service deploys from a versioned package rather than from a user-supplied service specification.

So when you want to check a deployed app, just remember to use SHOW APPLICATION SERVICES rather than SHOW SERVICES (I'll come back to this in the "Things to Watch Out For" section).

Architecture at a Glance

Here's the flow of how App Runtime gets an app running (this uses a Next.js project as the example, but the basic flow is the same for any Node.js app):

All the developer does is "write the app code and run snow app deploy." Building the container, placing it on SPCS, and wiring up authentication are all handled by Snowflake.

Official docs: About Snowflake App Runtime

Three Ways to Build Apps — How to Choose

There are currently three main ways to build apps on Snowflake. Plenty of people wonder "which one should I actually use?", so let's sort out where each fits.

	Streamlit in Snowflake	Snowflake App Runtime	Native App Framework
Primary language	Python	JavaScript / TypeScript	Any (packaged for distribution)
Best at	Data exploration, dashboards, analyst self-serve	Custom UI, multi-step business flows, rich web experiences	Distributing/monetizing apps and data across accounts
Frontend	No need to write it (handled for you)	Fully customizable	Fully customizable
Main use	Internal analytics tools	Internal web apps in general	Marketplace publishing, etc.

The official docs position Streamlit and App Runtime like this:

• Streamlit in Snowflake: Python-first and guardrailed. You can build a polished data app without writing any frontend code
• Snowflake App Runtime: The full power of the web. Ideal when you need custom UI or rich interactions that leverage the React / Next.js ecosystem

Put simply: Streamlit when you want to visualize data quickly, App Runtime when you want a web app with elaborate UI or business workflows, and Native Apps when you want to distribute to other companies or accounts.

My past articles on Snowflake apps & UI (some details may be a bit dated)

• Snowflake Data UI Guide - Choose the Right Tool for Every Analytics Use Case
• SiS Container Runtime - Run Streamlit Apps at a Fraction of the Cost

A Closer Look at the snowflake-apps Skill (CoCo)

This is the heart of the article. Snowflake App Runtime works on its own, but pairing it with CoCo makes the experience much smoother.

CoCo ships with a skill called snowflake-apps (a workflow definition specialized for a particular task), and it supports App Runtime app creation end to end.

Prerequisite: Setting Up CoCo Desktop

This article assumes the CoCo Desktop native app for Mac / Windows. If you haven't set it up yet, see the official documentation first:

• Official docs: Cortex Code Desktop

What the snowflake-apps Skill Takes Care Of

The snowflake-apps skill does more than just "scaffold an app." Following App Runtime's conventions, it sets up a foundation like this:

What the skill provides	Role
Next.js template	Copies a scaffold with Next.js 16 + React 19 + snowflake-sdk. No need to start from zero
lib/snowflake.ts	A Snowflake connection helper. Just call querySnowflake() to run SQL
snowflake.yml / app.yml	Auto-generates deployment config and app metadata (title, description, icon)
Authentication conventions	Built-in patterns for switching between Owner's Rights and Caller's Rights

This is a function for running SQL from the app's server side (server components or API routes) to fetch data from Snowflake. The skill takes care of authentication and connection management, so you can fetch data by simply calling querySnowflake().

import { querySnowflake } from "@/lib/snowflake"

// Run SQL from the app's server side to fetch data
const rows = await querySnowflake("SELECT * FROM MY_DB.MY_SCHEMA.SALES")

For how data access permissions are handled (the authentication mode), you have two choices. This is the spot that's easiest to get confused about if you're new to Snowflake's permission model, so let's lay it out in a table (Owner's Rights / Caller's Rights are also concepts that come up frequently on the SnowPro certification exams!).

Mode	Whose privileges run the SQL	When to use
Owner's Rights (default)	The app owner's (service identity) privileges	Shared dashboards / reference data where all users see the same thing
Caller's Rights	The signed-in user's own privileges	When data should differ per user, or you want row-level security to apply

To use Caller's Rights, you just add an option to the query.

// Run SQL with the signed-in user's privileges (row-level security, etc. apply)
const rows = await querySnowflake(
  "SELECT * FROM MY_DB.MY_SCHEMA.SENSITIVE_TABLE",
  { callersRights: true }
)

You also need to set executeAsCaller: true in app.yml, but the rest of the auth setup (token passing, etc.) is handled automatically by Snowflake. Being able to choose "whose privileges this runs as" in a single line is a really convenient point from a governance standpoint.

Without a connection string or an external auth layer, you can access data just by calling querySnowflake(). This mechanism is precisely why running an app right next to your Snowflake data is so easy.

The snow app CLI Command Surface

Deployment and lifecycle management are done with the Snowflake CLI's snow app command. snow app handles both Native Apps and App Runtime, and routes automatically based on the type field in snowflake.yml (snowflake-app for App Runtime).

That said, you don't need to memorize these commands one by one. Basically, CoCo gets the context from the snowflake-apps skill and runs the right commands for you, so all you have to do is say "deploy it." I'm listing the main commands here just so you understand "what's happening behind the scenes."

The main subcommands are as follows:

Command	Role
snow app setup	Initialize the project and generate snowflake.yml
snow app bundle	Resolve the artifacts to upload, locally (no connection required)
snow app validate	Validate snowflake.yml and the app structure ahead of time
snow app deploy	Run upload → remote build → deploy in one shot
snow app deploy --deploy-only	Deploy only, skipping the build (handy for faster redeploys)
snow app open	Open the deployed app in a browser
snow app events --last N	Fetch the app's container logs
snow app teardown	Remove the app and related resources

Official docs: Snowflake App Runtime CLI commands

Note: App Runtime commands including snow app setup require Snowflake CLI 3.17 or later (the latest at the time of writing is the 3.19 series). On older CLIs, snow app setup won't be found, so update with pip install --upgrade snowflake-cli first.

Basic Workflow

The basic flow for getting an App Runtime app up and running is these five steps.

Minimal Deployment Config

Running snow app setup generates snowflake.yml. The key point is type: snowflake-app, which marks it as App Runtime.

definition_version: "2"
entities:
  my_app:
    type: snowflake-app          # marks this as App Runtime
    identifier:
      name: MY_APP                # object name in Snowflake
      database: SNOWFLAKE_APPS    # target database
      schema: PUBLIC
    artifacts:
      - src: ./*
        dest: ./
        ignore:
          - node_modules
          - .next
          - .git
    query_warehouse: MY_QUERY_WH  # warehouse the app uses for queries

The app's title, description, and icon are set in app.yml's profile (app.yml itself is optional; if omitted, Node.js is auto-detected from the presence of package.json).

profile:
  label: "Sales Dashboard"
  description: "An app that visualizes EC sales"
  icon: public/icon.svg

Official docs: Getting started with Snowflake App Runtime / app.yml reference

Hands-On: Building a Sales Dashboard from a Prompt

From here, I'll walk through how I actually built a sales dashboard app in CoCo Desktop. The subject is the sales data of a fictional EC business, "Glacier Style" (GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA).

Step 1: Give CoCo a Prompt

In the CoCo Desktop chat, select /snowflake-apps (or use the "Build an app" starter card), then describe the app you want in natural language. Here's roughly the prompt I gave:

/snowflake-apps
Using the sales data in GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA,
build a sales dashboard that runs on Snowflake App Runtime, in Next.js.
Deploy the app itself to the GLACIERSTYLE_DB.APPS schema.

- Show KPIs (sales, order count, average order value, completion rate) as cards
- Filters to narrow by period, channel, and category
- Charts for sales by category, by channel, and the monthly trend
- Use a cool, glacier-inspired color palette

There are two points worth highlighting here. First, the prompt explicitly invokes the /snowflake-apps skill at the top. Second, it explicitly specifies GLACIERSTYLE_DB.APPS as the deployment target. If you don't specify a target, the app may be placed in your personal database and become impossible to share with other roles — so if you have internal sharing in mind, it's best to specify it up front.

When CoCo receives this prompt, it launches the snowflake-apps skill, first runs DESCRIBE on the target tables to understand the schema, then copies the Next.js template and implements app/page.tsx, the API routes, the chart components, and the styling — all in one pass, according to your requirements.

Step 2: Preview Locally

Once the implementation is done, CoCo starts a local development server (npm run dev) and checks that it works. During local development, the Snowflake connection automatically falls back to your local connection info (connections.toml), so you can verify the look and the numbers against real data before deploying.

Step 3: Deploy

Once the look and the numbers check out, it's time to deploy. Tell CoCo to "deploy it," and snow app deploy runs.

snow app deploy --verbose

This single command automatically runs through uploading the source → building the container remotely → creating the APPLICATION SERVICE. The first build takes a little while (more on that below), and when it's done, an authenticated URL is issued.

Step 4: Verify It's Running

Once deployment completes, you can access the app at a URL of the form https://<id>-<org>-<account>-<region>.snowflakecomputing.app/. This URL is protected by Snowflake SSO, so only authenticated users can use it.

You can also confirm the deployed app via SQL:

SHOW APPLICATION SERVICES IN SCHEMA GLACIERSTYLE_DB.APPS;

name     : GLACIER_SALES_APP
status   : RUNNING
database : GLACIERSTYLE_DB
schema   : APPS
url      : <id>-<org>-<account>-<region>.snowflakecomputing.app
source   : {"artifactRepository":"GLACIERSTYLE_DB.APPS.GLACIER_SALES_APP_REPO","version":"VERSION$1","alias":"LATEST"}

The status is RUNNING, and you can see it's deployed to GLACIERSTYLE_DB.APPS exactly as specified, under version management (VERSION$1). The empty compute_pool is because Public Preview uses a managed compute pool.

From handing over the prompt to getting a running URL, I needed no container knowledge and built no infrastructure. Seeing how easy "putting an app right next to the data" has become was genuinely impressive when I tried it.

Things to Watch Out For

Here are some points worth keeping in mind when you actually build an app — things you won't see by just skimming the official docs. Knowing them up front should help you move along smoothly without stumbling.

1. Mind the CLI version

If your Snowflake CLI is old, snow app setup may not even exist (the older snow app is mostly Native App subcommands), and you won't be able to initialize App Runtime. CLI 3.17 or later is required, so it's safest to update with pip install --upgrade snowflake-cli before you start.

2. snow app setup needs a warehouse, and watch the deploy target

snow app setup requires a query warehouse. If you see a Missing warehouse error, pass --warehouse or set the account parameter DEFAULT_SNOWFLAKE_APPS_QUERY_WAREHOUSE.

The deploy target deserves extra care. The deployment target in the snowflake.yml that setup generates can resolve, by default, to your personal database (USER$<username>). If you want to place it in a regular DB / schema like this time (GLACIERSTYLE_DB.APPS), it's a good idea to review and adjust the identifier and code_workspace in the generated snowflake.yml. If you state the target in your prompt, CoCo will reflect it in this config for you. Note that apps placed in a personal database can't be shared with other roles, so if you're planning internal sharing, specify a regular DB / schema.

3. Public Preview uses a managed compute pool

App Runtime runs on an SPCS compute pool, but during Public Preview a managed compute pool (SYSTEM_COMPUTE_POOL_CPU) is used automatically. As a result, you don't need to create a compute pool yourself, nor set up an External Access Integration for fetching npm packages (the remote build and external fetching are handled on the Snowflake side). Being able to start without worrying about infrastructure is a big plus.

4. Deployment spends more time on "endpoint provisioning" than the build

With snow app deploy, the remote build itself finishes relatively quickly, and the subsequent endpoint provisioning (Endpoints provisioning in progress...) can take a few minutes. Even if the log looks stuck on the same line, work is progressing — so wait until App ready at https://... appears. When you only want to reflect code changes quickly, you can skip the build with snow app deploy --deploy-only.

5. Watch the connection's role during local development

During local npm run dev, querySnowflake() automatically falls back to the default connection in ~/.snowflake/connections.toml. If the connection has no role set, it runs with the default role, which can lead to a Database '...' does not exist or not authorized error. Set a role that can access the target data on the connection, or specify it via the SNOWFLAKE_ROLE environment variable.

6. A deployed app doesn't show up in SHOW SERVICES

Because App Runtime runs as a separate object type, APPLICATION SERVICE, a deployed app does not appear in SHOW SERVICES. Use SHOW APPLICATION SERVICES to check it. The reliable way to judge a successful deploy is to look at the CLI output (App ready at https://... and the URL).

7. (SQL tip) Watch for duplicates in dimension tables

This is a little aside from the app itself, but there's one thing to watch in your aggregation SQL too. If a dimension table contains duplicate rows for the same ID, joining it directly will inflate your counts (fanout). Deduplicate first with QUALIFY ROW_NUMBER() OVER (PARTITION BY <id> ORDER BY <id>) = 1 before joining, and you'll get correct aggregates. Checking the nature of your data is essential even when building an app.

Business Value and Use Cases

The technical ease is what we've seen so far, but where App Runtime really shines is the business and organizational angle.

Value	Details
Governance stays intact	Because the app runs inside Snowflake's security perimeter, it inherits RBAC, audit logging, SSO, and data governance as-is
No data movement	No data copies or external API layer needed, reducing the risk of data leaking outside or to the app side
Integrated authentication	An authenticated URL is issued automatically — no separate login infrastructure required
Accelerates in-house development	Since Snowflake handles infrastructure, Docker, and server management, you can ship internal apps fast without creating shadow IT

Concrete use cases include:

• Internal data visualization dashboards: Department-level KPIs delivered in an easy-to-read custom UI
• Data entry / update forms: Business apps where staff update master data or statuses from the browser
• Approval workflows: Rich business apps with multi-step request/approval flows
• Internal search / reference tools: Reference apps that control what each user can see via Caller's Rights

For organizations where "the data is in Snowflake, but the apps that use it rely on outsourcing or a separate platform," this looks like an option that meaningfully lowers the bar for in-house development.

Limitations

As handy as it is, there are some limitations to be aware of at this Public Preview stage.

Note (limitations during Public Preview):

• Not available on trial accounts (a paid account is required)
• During Public Preview, a managed compute pool tends to be used, and a user-specified pool may not be reflected
• Apps deployed to a personal database (USER$...) can't be shared with other roles. To share, place it in a regular database
• snow app deploy is not idempotent (no overwrite) — each run produces a new package version
• The supported stack during Public Preview centers on Node.js / Next.js (Python support is also planned, and coverage is expected to expand over time)

Please check the official documentation for the latest limitations.

Official docs: Snowflake App Runtime limitations

Conclusion

So, what did you think of Snowflake App Runtime?

Let's recap the key points of this article:

• App Runtime is a new platform that lets you deploy full-stack web apps (Next.js and friends) inside Snowflake (as an SPCS APPLICATION SERVICE)
• No infrastructure, Docker, or auth implementation needed — you can publish an app while inheriting SSO and governance
• With CoCo's snowflake-apps skill, you go from prompt to scaffold to local preview to deploy in one continuous flow
• When you actually build one, there are points worth knowing up front — the CLI version, specifying the deploy target, and the role during local development

The approach of "running a real web app right next to your data" looks set to make in-house app development — previously a time-consuming effort — much more approachable. The supported stack and features are likely to keep expanding, so I'll keep watching how it evolves.

This is still an area with limited information out there, so I'd love for you to get hands-on and share what you discover. Let's grow this new app-building experience together!

Promotion

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20260605) Initial post

Original Japanese Article

Snowflake App Runtime 入門 - プロンプトひとつでデータの隣に本格Webアプリをデプロイする！

zenn.dev