# GitHub Repository Provisioning

> zop.dev provisions a github_repository with branches, branch protection, 3 GitHub teams (admin, editor, viewer) and GitHub Actions secrets pre-populated for deployment. The PAT powering it is read from the connected cloud's own secret store: AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault.

Source: https://zop.dev/integrations/provision/cross-provider/github-repository-provisioning
Updated: 2026-08-19

---

Every service needs a repository with the right protections and CI credentials. zop.dev provisions GitHub repos with branch protection, team access tiers, and deployment secrets pre-configured for each cloud.

## Repository, branch protection, teams, and CI secrets

github_repository, branches, branch protection, three GitHub teams (admin/editor/viewer), and GitHub Actions secrets.

## Repository config with tiers mapped to teams

```text
Repository and branch configuration; access tiers mapped to teams.
```

## Where the GitHub token is read from

The GitHub PAT is read from the cloud's own secret store: AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault, depending on provider.

## The PAT never lives in config

Provisioning GitHub resources requires a personal access token, and where that token lives is
the design decision here. It is read from the secret store of whichever cloud is connected,
not from platform configuration: Secrets Manager on AWS, Secret Manager on GCP, Key Vault on
Azure. The token that can create repositories and write CI secrets is a high-value
credential; keeping it in the cloud's audited store means access to it is loggable and
revocable in one place, and rotating it is a secret-store update rather than a config hunt.

## Teams mirror the platform tiers

The 3 GitHub teams (admin, editor, viewer) carry the same tier model the platform applies to
clusters and namespaces into source control. Access reviews get simpler when the question "who
can merge to this service" has the same shape as "who can deploy it," and onboarding becomes
two group memberships instead of a scatter of per-repo collaborator grants.

## CI is born knowing how to deploy

GitHub Actions secrets are written at provisioning, cloud-appropriate for wherever the service
will run. The first pipeline on the first push can authenticate and deploy. Nobody pastes
credentials into repository settings, which is both a convenience and the removal of the most
common way deploy credentials leak or drift out of rotation. Those secrets are still
credentials with lifetimes; the platform writing them does not exempt them from rotation.

## Branch protection is the persistent part

Branches and protection rules arrive configured, so the review and status-check gates exist
before the first commit rather than after the first incident. Worth remembering at teardown:
the repository is an entry point to cloud resources, not their owner. Deleting a repo removes
code and CI wiring, while everything it deployed keeps running and billing until torn down
through the platform.