Git providers
The Git section (top nav) connects your code host so the whole CI/CD setup happens in-panel — no bouncing to GitHub to make a repo, paste a deploy key, or wire a webhook.
Supported providers
| Provider | Auth | What it unlocks |
|---|---|---|
| GitHub | Fine-grained or classic PAT | repos, deploy keys, webhooks, account SSH keys |
| Gitea | Instance URL + PAT | same — self-hostable, fits the “own everything” story |
Both are connected independently (you can wire both at once). Credentials are stored encrypted-at-rest, keyed per provider.
Connect
Git → GitHub (or Gitea) → Connect.
- GitHub — create a token at github.com/settings/tokens?type=beta. Repository access: All repositories (or the ones you want). Permissions: Metadata: Read (required to list private repos), Contents: Read, Administration: Read/Write (deploy keys), Webhooks: Read/Write. A classic token with the
reposcope also works and is simpler. - Gitea — generate a token under Settings → Applications with
repo,admin:public_key,admin:repo_hookscopes. Enter your Gitea URL + the token.
What you can do
Once connected, browse your repos. Per repo:
- Create repo — name, description, private/public, auto-init README — one modal
- Deploy keys — list / add / delete (read-only by default), so a server can clone over SSH
- Webhooks — list / add / delete; point one at a Mezzanine workflow’s webhook URL to deploy on push
- Account SSH keys — list / add / delete your account-level keys
Closing the CI/CD loop
The end goal: the deploy-workflow setup becomes one screen. Today the building blocks all exist in-panel — create the repo in Git, grab the server’s key from the Deploy Key card on its server page, add it as a deploy key on the repo, and register the workflow’s webhook from the repo’s Webhooks tab. (A future tweak wires these together automatically in the New Workflow wizard.)
All Git mutations require the admin role.