GitHub Repository Provisioning
What does zop.dev create for 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.
| Field | Value |
|---|---|
| Cloud | cross-provider |
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
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.