Deploying with Snowflake App Runtime¶

When you’re ready to deploy your app to Snowflake, run snow app deploy. The command uploads your source, builds it remotely, and creates or upgrades the Application Service that serves your app at a stable live URL. Use --upload-only, --build-only, or --deploy-only to run one phase at a time.

The build job and the Application Service are separate workloads with different compute, database placement, and outbound access rules. app.yml defines install, build, and run commands; snowflake.yml controls upload paths, deploy destination, and optional settings such as artifact_repository.

Deploy pipeline overview¶

If a run fails partway through, retry just the failed phase instead of rerunning the full pipeline. Only one phase flag can be used at a time.

Upload phase¶

The upload phase copies project files named in your snowflake.yml artifacts section to Snowflake storage. For a shared deploy destination, uploaded source goes to an internal stage (code_stage). When the deploy destination is your personal database, Snowflake uses a workspace (code_workspace) instead, because personal databases don’t support stages.

The ignore list in snowflake.yml excludes local-only paths such as node_modules and .next from upload.

Build phase¶

The build phase runs a short-lived Snowpark Container Services job that executes the install and build commands from your app.yml manifest (or auto-detects those steps from your project layout). Each successful build adds an immutable package version to the artifact repository configured for the app.

The build job and the Application Service that serves your app are separate workloads with different network policies and lifetimes.

Build-time outbound access does not carry over to the running app. Each phase has its own egress policy.

Where the build runs¶

Snowflake provisions build infrastructure for you. You don’t create a dedicated compute pool for the build when you use the standard snow app deploy workflow.

Compute¶

The build runs as a short-lived Snowpark Container Services job on a Snowflake-managed compute pool that Snowflake provisions for your account.

Where each workload runs¶

The build job, the artifact repository, and the Application Service land in different places:

The build job always runs in your personal database so you can install and build before your account has shared deploy defaults or broad privileges on a team schema. The Application Service runs in your deploy destination. Package versions are stored in the artifact repository you configure.

Artifact repository¶

By default, Snowflake stores package versions in an artifact repository named <app-name>_REPO in your deploy destination (same database and schema as the entity identifier). On the first build, Snowflake creates the repository if it does not already exist (CREATE ARTIFACT REPOSITORY IF NOT EXISTS ... TYPE = APPLICATION).

Set a different name or location in snowflake.yml with artifact_repository. Multiple apps can point at the same repository if you configure them that way. The deploy phase references that repository when it creates or upgrades the Application Service; the repository location does not determine where the service runs.

Each successful build adds a new immutable package version. The deploy phase loads a package from that repository (typically LATEST) into the Application Service in your deploy destination.

Default outbound access during build¶

By default, remote builds can reach a small set of external hosts so Node.js projects can download npm packages and common frontend assets (Google Fonts).

Snowflake applies an origin-based allowlist for remote build jobs. Allowed destinations are scoped to specific host and port pairs, not open internet access.

These defaults cover most Node.js app builds during public preview.

Custom outbound access during build¶

If your build must reach additional hosts (for example, a private package registry or a third-party CDN), create a network rule and an External Access Integration (EAI), then reference the EAI in your snowflake.yml with the build_eai entity field:

entities:
  my_app_name:
    type: snowflake-app
    build_eai: MY_CUSTOM_EAI

The EAI must reference a network rule with MODE = EGRESS and TYPE = HOST_PORT. Snowflake merges EAI-derived hosts with the default allowlist when both apply.

You can also set a default build EAI at the account level with DEFAULT_SNOWFLAKE_APPS_BUILD_EXTERNAL_ACCESS_INTEGRATION, or pass --build-eai during snow app setup. See How field values are resolved for precedence between snowflake.yml, account parameters, and CLI flags.

Disabling default build egress¶

Account administrators can turn off automatic outbound access during remote builds. When default egress is disabled, builds that rely on npm or Google Fonts fail at the dependency-fetch step unless the developer supplies an EAI (for example, through build_eai) that covers the required hosts.

Example (requires a role that can change account parameters, such as ACCOUNTADMIN):

ALTER ACCOUNT SET ENABLE_REMOTE_BUILD_SERVICE_EGRESS_DESTINATIONS = FALSE;

To re-enable npm and Google Fonts without turning the master switch back on, create an EAI and set build_eai in snowflake.yml as described in Custom outbound access during build.

Deploy phase¶

The deploy phase is when your app goes live. Snowflake takes the package version from the build phase and runs it as an Application Service at your deploy destination (the identifier.database and identifier.schema in snowflake.yml, or defaults from account administrator setup).

On the first deploy, Snowflake creates a new Application Service from the package in your artifact repository (typically the LATEST version). On later deploys, it upgrades that same service to the new package. Your app URL does not change.

The artifact repository holds the built packages; the Application Service runs where your snowflake.yml entity points. Those locations are configured independently. See Where each workload runs above.

How configuration files fit together¶

See also¶

• Getting started with Snowflake App Runtime: end-to-end walkthrough with Cortex Code or the CLI
• snow app deploy command reference: syntax, phase flags, and examples
• Optional app.yml manifest: install, build, and run commands used during the build phase
• Snowflake App Runtime limitations: build timeout and other public preview limits
• Configure service egress: creating network rules and EAIs for SPCS workloads