Snowflake Terraform Stack Library

Infrastructure-as-code templates for managing Snowflake account governance, shared platform services, and workload resources with Terraform.

Overview

This repository provides a reusable layout for operating multiple Snowflake environments (test, stage, and beyond). Each stack is an independent Terraform root, allowing teams to deploy, upgrade, and audit Snowflake objects with clear separation of duties.

Key capabilities:

• Account governance roles and users managed through code.
• Shared platform components (databases, warehouses, resource monitors, integrations, network rules).
• Workload resources (schemas, stages) wired to platform outputs.
• SnowSQL-assisted workflows for operations not yet supported natively by the Terraform provider (database rename, external access integrations).

Repository structure

live/
  test/
    account_governance/
    platform/
    workloads/
    config/
  stage/
    account_governance/
    platform/
    workloads/
    config/
modules/

Every directory under live/<env>/... contains its own Terraform state, variables, and provider configuration. Environment-specific runbooks live alongside each stack.

Environments

• Test (live/test) – sandbox for validating configuration and Snowflake changes.
• Stage (live/stage) – pre-production environment mirroring the test structure with separate credentials and state.

To add a production environment, copy one of the existing environment folders (for example, duplicate live/test to live/prod), adjust the account.auto.tfvars values, and update the configs/*.tfvars files with production-safe names. The same pattern can be used to manage additional sandboxes while keeping a consistent directory structure.

Update live/<env>/account.auto.tfvars (or matching environment variables) with organization, account locator, provisioning user, key material, and role aliases before applying any stack.

Core workflows

1. Account governance – roles and users under account_governance/.
2. Platform services – databases, warehouses, resource monitors, storage integrations, network rules, and external access integrations under platform/.
3. Workloads – schemas and stages under workloads/, typically consuming outputs from platform stacks.
4. Database rename – leverage live/<env>/platform/database_rename, which issues SnowSQL ALTER DATABASE statements and guides you through terraform state mv / terraform import. Terraform cannot perform in-place renames because the provider marks the database name as ForceNew (see live/<env>/platform/database_rename/RENAMING_LIMITATIONS.md), so this module executes the rename via SnowSQL local-exec and then reconciles state with targeted move/import steps.
5. External access integrations – currently rely on SnowSQL via local-exec; ensure the referenced SnowSQL profile is configured before applying.

Tooling requirements

• Terraform CLI v1.5+ with the Snowflake provider.
• Snowflake account roles with sufficient privileges (ACCOUNTADMIN, SECURITYADMIN, SYSADMIN).
• SnowSQL CLI for rename and external access workflows.
• Optional: AWS credentials for the sample S3 remote state backend definitions.

Documentation

• GETTING_STARTED.md – end-to-end setup guide covering prerequisites, credential management, execution order, and troubleshooting.
• ADOPTING_EXISTING_SNOWFLAKE_ACCOUNT.md – how to adopt and manage an already provisioned Snowflake account with Terraform (inventory, import, guardrails).
• RUNBOOK.md – Terraform runbook for the stage environment.
• live/test/README.md & live/stage/README.md – environment-specific runbooks and SnowSQL callouts.
• live/<env>/platform/database_rename/RENAMING_LIMITATIONS.md – rationale for the SnowSQL rename workflow and Terraform state alignment steps.

Support & troubleshooting

• Run terraform plan regularly to detect drift before applying.
• Use TF_LOG=DEBUG when diagnosing provider or SnowSQL issues.
• Keep Snowflake credentials secure; prefer environment variables or secret stores over committed files.

Contributions that improve automation, linting, or CI/CD are welcome—see FUTURE_SCOPE.md for upcoming enhancements.

Try It On a Free Snowflake Trial

You can validate this stack in a fresh Snowflake trial account with minimal setup:

• Create a trial: Sign up for a Snowflake trial and choose your preferred cloud/region.
• Generate a key pair (for JWT auth):
  • openssl genrsa -out ~/.snowflake/terraform_user_key.pem 2048
  • openssl pkcs8 -topk8 -inform PEM -outform PEM -in ~/.snowflake/terraform_user_key.pem -out ~/.snowflake/terraform_user_key.p8 -nocrypt
  • openssl rsa -in ~/.snowflake/terraform_user_key.pem -pubout -out ~/.snowflake/terraform_user_key.pub
• Attach the public key to a Snowflake user:
  • In Snowflake (Worksheet or UI), set the public key on a service user (or your trial user) using the contents of terraform_user_key.pub, for example: ALTER USER <USER_NAME> SET RSA_PUBLIC_KEY='<PUBLIC_KEY_CONTENT>';
  • Ensure the user has enough privileges (for a trial, ACCOUNTADMIN is simplest; for stronger isolation, grant SECURITYADMIN/SYSADMIN).
• Configure this repo for your trial account:
  • Copy live/test/account.auto.tfvars and set organization_name, account_name, provisioning_user, and private_key_path to your ~/.snowflake/terraform_user_key.p8.
  • Review the live/test/configs/*.tfvars files and adjust names as needed.
• Run a minimal plan/apply (example: databases stack):
  • cd live/test/platform/databases
  • terraform init
  • terraform plan -var-file=../../account.auto.tfvars -var-file=../../configs/create_database.tfvars
  • terraform apply -var-file=../../account.auto.tfvars -var-file=../../configs/create_database.tfvars

License

Licensed under the Apache License, Version 2.0. See LICENSE for details.