CI/CD

Use your CI/CD system to deploy to Snowflake. Snowflake publishes integrations for GitHub, GitLab, and Azure DevOps that automate deployments of DCM projects, Snowpark applications, Snowflake Native Apps, and SQL scripts. Each integration installs Snowflake CLI on the runner and configures authentication. On any other CI system that can run a shell command, install Snowflake CLI yourself.

Note

You do not need to create a Git repository object in Snowflake to deploy from CI/CD. The pipeline checks out your repository on its runner and deploys to Snowflake using the appropriate command. Create a Git repository in Snowflake only when Snowflake needs access to files in the repository.

For broader DevOps concepts including declarative object management and environment strategy, see DevOps with Snowflake.

Supported CI/CD integrations

Snowflake maintains the following first-party CI/CD integrations. Each integration installs Snowflake CLI on the runner and configures authentication to Snowflake.

IntegrationStatusAuthentication (recommended)Reference
GitHub ActionsGenerally availableWorkload identity federation (OIDC)GitHub Actions
GitLab CI/CD ComponentPublic previewWorkload identity federation (OIDC)GitLab CI/CD component
Azure DevOps ExtensionGenerally availableWorkload identity federation (OIDC through Azure service connection)Azure DevOps extension

Note

If you use Jenkins, Bitbucket Pipelines, CircleCI, or another CI system that is not listed in the preceding table, you can install Snowflake CLI with a single shell command in your pipeline. See Other CI systems.

Common Snowflake-side setup

All first-party CI/CD integrations follow the same pattern on the Snowflake side:

  1. Create a service user that the pipeline authenticates as.
  2. Configure the service user’s authentication method. Snowflake recommends workload identity federation (WIF) with OpenID Connect (OIDC) so that no long-lived secrets are stored in the CI system.
  3. Grant the service user the roles it needs to deploy your objects.

Authenticate with workload identity federation (OIDC)

With OIDC, the CI runner obtains a short-lived identity token that Snowflake validates directly. Each CI platform publishes tokens from a different issuer with a different subject claim format; the integration reference pages document the exact values to use.

A minimal service user definition looks like the following. Replace the ISSUER and SUBJECT values with the ones required by your CI platform (see the corresponding integration reference page).

CREATE USER <username>
  TYPE = SERVICE
  WORKLOAD_IDENTITY = (
    TYPE = OIDC
    ISSUER = '<ci-platform-issuer>'
    SUBJECT = '<ci-platform-subject>'
  );

For background on Snowflake WIF, see Workload identity federation.

Authenticate with a key pair or password

When OIDC is not available (for example, when you need to support older Snowflake CLI versions or on-premises CI runners), use key pair authentication. Store the private key as a CI secret and pass it through the environment using SNOWFLAKE_PRIVATE_KEY_RAW (for a temporary connection) or SNOWFLAKE_CONNECTIONS_<NAME>_PRIVATE_KEY_RAW (for a named connection).

Password authentication is supported for legacy workflows but is not recommended for production CI/CD. See Managing Snowflake connections for the full list of authentication parameters.

Configuration files and environment variables

Most CI/CD workflows combine a committed config.toml with secrets injected through environment variables. The following precedence rules apply:

  • Command-line parameters override everything.
  • Environment variables that target a specific connection parameter (for example, SNOWFLAKE_CONNECTIONS_MYCONNECTION_PASSWORD) override config.toml.
  • Values defined in config.toml are used when no override is provided.
  • Generic environment variables such as SNOWFLAKE_USER apply last.

For details, including a full parameter reference, see Managing Snowflake connections.

Other CI systems

You can run Snowflake CLI on any CI runner that can execute a shell command. The canonical single-line installation uses uv:

uv tool install snowflake-cli
snow --version

For installation options on specific operating systems, see Installing Snowflake CLI. For connection management (including using environment variables to avoid storing credentials on the runner), see Managing Snowflake connections.

Typical pipeline stages

A Snowflake CI/CD pipeline typically progresses through three stages: validate proposed changes on a pull request, deploy them on merge, and verify the result. The same pattern works on every CI platform; only the syntax changes.

StageWhat it doesExample tools
ValidateComputes the changes that would be applied to the target environment without modifying anything. Post the output as a PR comment so reviewers can confirm intent before merging.snow dcm plan for DCM Projects.
DeployApplies the validated changes to the target environment. Typically runs after a pull request is merged to the main branch.snow dcm deploy for DCM Projects; snow sql -f <file> for standalone SQL scripts; snow snowpark deploy for Snowpark applications.
VerifyRefreshes derived data and runs expectation checks to confirm the deployment produced the expected results.snow dcm test to run expectation checks.

Security recommendations

  • Use workload identity federation (OIDC) wherever your CI system supports it. Avoid storing long-lived credentials in CI secrets.
  • Create a dedicated service user for each pipeline environment (for example, one user per repository or per environment). Grant only the roles required for that pipeline.
  • Use Controlling network traffic with network policies to restrict which source IPs can authenticate as the service user when possible.
  • Do not commit config.toml files that contain credentials. Commit only the connection skeleton and supply secrets through environment variables.
  • Rotate private keys and passwords on a regular schedule if you can’t adopt OIDC.