snowflake.yml project definition for Snowflake App Runtime¶

The snowflake.yml project definition tells the Snowflake CLI where and how to deploy your app. This page documents the schema for a Snowflake App Runtime project, where the entity is type: snowflake-app.

A snowflake.yml is a Snowflake CLI project definition. For entity keys, identifiers, mixins, templating, and other patterns the CLI applies to all project files, see Specify entities. The rest of this page covers only the Snowflake App Runtime specifics.

snowflake.yml is separate from the optional app.yml build manifest. snowflake.yml controls deployment (destination, code storage, warehouse, and compute). app.yml controls the remote build (install, build, run, artifacts, and display profile).

Example¶

definition_version: "2"

entities:
  myapp:
    type: snowflake-app
    identifier:
      name: MYAPP
      database: MY_DB
      schema: MY_SCHEMA
    artifacts:
      - src: ./*
        dest: ./
        ignore:
          - node_modules
          - .env*
          - .git
    query_warehouse: MY_WH
    code_stage: MYAPP_CODE

Use code_workspace instead of code_stage to store code in a workspace rather than a stage. The two fields are mutually exclusive.

snowflake.yml schema for snowflake-app entities¶

Fields¶

The following fields are supported for snowflake-app entities:

Code storage object shapes¶

When you write code_stage or code_workspace as an object, use these fields:

• code_stage: name (required), schema, database, and encryption_type (default SNOWFLAKE_SSE).
• code_workspace: name (required), schema, and database.

Validation rules¶

• Code storage is mutually exclusive. Setting both code_stage and code_workspace fails with Specify either code_stage or code_workspace, not both.
• The external access integration is nullable. build_eai accepts null, which is treated the same as omitting it.
• Code storage accepts three forms. Write code_stage and code_workspace as an object, a bare name, or a fully qualified DB.SCHEMA.NAME string. When you use a bare name (or omit the database or schema), the CLI resolves those parts against the app’s database and schema at deploy time.

How field values are resolved¶

The CLI resolves each field’s value using a four-tier precedence. The first source that provides a value wins:

1. snowflake.yml: Your entity fields (query_warehouse, build_eai, artifact_repository, and the app’s database and schema).
2. Account parameters: Your DEFAULT_SNOWFLAKE_APPS_* parameters (see the table below).
3. Built-in defaults: The CLI’s fallback values. For example, artifact_repository becomes <app-name>_REPO, and if you have a personal database, database becomes that database and schema becomes PUBLIC.
4. Current session: Your connection’s warehouse, database, and schema.

If an account-configured destination database or schema is set but your current role lacks the privileges to deploy there, the CLI warns you and falls back to your personal database.

Account parameters you can set: