Getting started with Snowflake App Runtime¶
Install Cortex Code CLI or Cortex Code Desktop and the Snowflake CLI, then deploy your first app. Use Cortex Code to build from a description, or the Snowflake CLI if you already have code.
Set up your environment¶
Before you can build or deploy, install Cortex Code (CLI or Desktop) and the Snowflake CLI on your machine. Use the install guides below, then confirm the Snowflake Apps command surface in the next section.
Cortex Code¶
Use Cortex Code CLI or Desktop to scaffold,
test, and deploy apps from natural language. Both bundle the snowflake-apps
skill and use the Snowflake CLI for deployment.
Cortex Code CLI (macOS, Linux, and Windows):
- Install and connect: Cortex Code CLI (including Windows instructions)
- Custom skills and extensions: CoCo CLI extensibility
Cortex Code Desktop (macOS and Windows):
- Install and sign in: Installation, onboarding, and authentication
- Build and deploy Snowflake App Runtime apps: Building apps
(starter card, in-IDE live preview, Apps view, and
snow app deploy) - Product overview: Cortex Code Desktop
Snowflake CLI¶
Install the Snowflake CLI using Installing Snowflake CLI.
Confirm you’re on the latest version with
snow helpers check-version:
If that command isn’t recognized, your CLI is too old: follow the installation guide and upgrade. The command reports the version you have, the latest published version, and whether an upgrade is available.
Other requirements¶
- Snowflake account: Use a paid account (trial accounts don’t support App Runtime).
- Shared deploy defaults (recommended for team apps): For apps you plan to share, ask an account administrator to complete account administrator setup once, so deploys land in a shared database the whole team can use. Before those defaults are configured, you can deploy to your personal database to build and experiment; you just can’t grant other roles access to apps there.
- Node.js 22+: Version 22 or later on your machine for local development
(
npm install, tests,npm run dev). Download Node.js (https://nodejs.org/en/download).
Build and deploy with Cortex Code¶
Cortex Code assistants scaffold, build, test, and deploy Snowflake apps from a natural language description.
Step 1: Describe your app¶
Use the snowflake-apps
skill in your prompt:
In chat, type /, select snowflake-apps, and describe what you want to
build. See entry points
for other ways to start.
The assistant scaffolds a Next.js project with a working UI, Snowflake data
access, and an app.yml
manifest.
Step 2: Test locally¶
Ask the assistant to run the dev server and open the app in your browser. In Cortex Code Desktop, the Agent Browser shows a live preview as you go. Describe changes in chat to update the app.
Step 3: Deploy¶
When you’re happy with the app:
The assistant runs snow app deploy, which runs the full upload, build, and
deploy pipeline. You get a live URL when the deploy phase completes.
Step 4: Open the app¶
Ask the assistant to open the app, or use the URL from deploy output. In Cortex Code Desktop, you can also use the Apps view. The URL uses Snowflake SSO.
Step 5: Share with other roles¶
To let other roles open your app, ask the assistant to share it. The app must
live in a standard database (for example SNOWFLAKE_APPS after
account administrator setup),
not a personal database.
In Cortex Code Desktop, you can also use Share on the app in the Apps view.
Behind the scenes, this grants USAGE on the database, schema, and Application
Service. To run it yourself (replace MY_APP_NAME and ANALYST with your
service name and role):
For OPERATE, MONITOR, and revoke patterns, see
Access control for Snowflake App Runtime.
Step 6: Iterate¶
Make changes and redeploy. Each deploy produces a new package version and alters the running service in place. The URL stays the same.
Build and deploy with the CLI¶
If you have an existing application or prefer working directly with code, use the Snowflake CLI. Cortex Code isn’t required for this path.
Step 1: Initialize your project¶
From your project directory, run snow app setup to generate an
app.yml
manifest:
Pass --app-name my_app_name when you want an explicit Snowflake identifier
instead of the name derived from the current directory. To target a specific
destination, pass --database, --schema, or --warehouse. Setup writes those
values into app.yml as explicit overrides.
This creates an app.yml in the current directory that uses defaults from
account administrator setup.
After setup, the file typically references the shared SNOWFLAKE_APPS database.
Leave code_stage and code_workspace unset unless you need to pin a backend;
the CLI picks a workspace or stage at deploy time. For example:
Setup resolves database, schema, and query_warehouse in this order: the
explicit --database, --schema, and --warehouse options; then account
defaults from administrator setup; then the personal database default (when
account defaults aren’t set). After account setup, you normally don’t pick
these manually. app.yml does not fill an unset database from the
active CLI connection. The ignore list excludes build output and local-only
files from upload.
Run with --dry-run to preview the resolved configuration without writing
the file.
If the project already has a snowflake.yml, see
Migrate from snowflake.yml to app.yml. Named targets
are optional; add them when one project needs more than one deploy
configuration, whether that’s a development, stage, and production lifecycle,
several accounts with slightly different configuration, or variants of the app
for different audiences. For a walkthrough, see
Deploy targets. For the
snow app setup options, see the
snow app setup
command reference.
Step 2: Deploy¶
From your project directory:
The CLI runs the full snow app deploy pipeline: upload, build, and deploy.
When the deploy phase finishes, it prints the live Application Service URL. The
URL looks
like:
This URL is stable across redeploys. It doesn’t change when you deploy a new package version.
Step 3: Open your app¶
Use snow app open --print-only to print the URL without opening a browser.
Use snow app open --settings to open the app in Snowsight instead of the live
endpoint.
Step 4: Share with other roles¶
Grant USAGE on the database, schema, and Application Service so another role
can open the app. Use the database and schema from your app.yml (for example
SNOWFLAKE_APPS.PUBLIC):
You can’t share apps deployed to a personal database. For more patterns, see Access control for Snowflake App Runtime.
What deploy does¶
snow app deploy
uploads source, builds remotely, and creates or alters the Application
Service. See
Deploying with Snowflake App Runtime
for build infrastructure, artifact repository storage, egress, and phase details.
If a deploy fails partway through, retry one phase with --upload-only,
--build-only, or --promote-only. See
Retrying a failed deploy.
With account administrator setup
complete, snow app setup and snow app deploy use shared destination defaults.
You focus on application code; Snowflake handles packaging and service lifecycle.
Query Snowflake from your app¶
After you have a live URL, your app can query Snowflake with no credentials
to manage. The snowflake-apps skill adds lib/snowflake.ts, which wraps
the driver; call querySnowflake from that module to run SQL.
For owner’s rights versus caller’s rights and caller grants, see Query Snowflake. For what Snowflake injects into the running app, see Runtime environment. For how to design those queries and secrets so they stay least-privilege, see Developing secure Snowflake App Runtime applications.
Other CLI commands¶
Beyond snow app setup, snow app deploy, and snow app open, the
CLI provides additional commands for managing your app lifecycle:
| Command | Description |
|---|---|
snow app validate | Check that the target database and schema exist and that the project can
be bundled. Use |
snow app bundle | Copy resolved artifacts into |
snow app events | Fetch observability streams for the Application Service. Default is
recent container logs ( |
snow app teardown | Drop the Application Service and clean up associated objects (stage or
workspace files). Use |
Retrying a failed deploy¶
If snow app deploy fails partway through, you can retry just the phase
that failed instead of starting over:
snow app deploy --upload-only: re-upload source files without rebuilding or redeploying.snow app deploy --build-only: re-trigger the build without re-uploading or redeploying.snow app deploy --promote-only: create or alter the service without re-uploading or rebuilding. (--deploy-onlyis a deprecated alias.)
Only one of these flags can be used at a time.