Docs
Open the console →
Guides

Git connections & GitOps

Connect GitHub, GitLab or Bitbucket to Snowtrol with a PAT (encrypted, never echoed): infra repos receive the hydrated Terraform as standalone-applyable native HCL; application repos feed pipelines.

The Git screen (/git) connects real repositories with a personal access token. The token is validated against the provider on connect, stored only as an AES-256-GCM envelope, and never returned by any API (responses carry tokenSet). Managing connections needs the manage cloud accounts capability; any member can view them.

Repo types

  • Infra (default) — the Terraform GitOps target. Connecting initializes the repo: creates the branch if absent, commits a Terraform scaffold, and claims a single-owner marker keyed to your 14-digit org id — a repo+branch already owned by another organization is refused with a 409. On every apply, the workspace's composed module is committed as standalone-applyable native HCL (terraform/workspace-<id>/main.tf + versions.tf + provider.tf + README.md, local backend, no secrets) so a plain terraform init && apply from a clone can recreate the estate outside Snowtrol. Purging a workspace prunes its directory.
  • Application — app source code, a pipeline source. Connecting writes only the single-owner marker, never the Terraform scaffold.

An organization may connect multiple infra repos, and each Terraform workspace chooses which one it hydrates into (the workspace-create forms have an infra-repo selector; the default is the org's first writable infra repo). Repo writes are always best-effort: a missing or read-only repo never fails an apply or import — the failure is audited (git.repo_write_failed) and surfaced.

Permissions the token needs

Read access is enough to connect healthy; the GitOps commits need Contents: write. A read-only token connects with a clear "grant Contents: write" message rather than an error.