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 account.

Multiple accounts

You can connect several accounts per provider — e.g. a personal GitHub and an organisation, or two separate orgs. After connecting, an Account chip row appears on the Git page: click a chip to switch, + Add account to connect another, and Remove account to disconnect just that one.

Everything — repos, file browser, deploy keys, webhooks, uploads, and the deploy wizard’s repo picker — acts as the selected account. A single org-scoped token already covers every repo in that org, so for a multi-app portfolio under one org you usually need just one account.

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 repo scope also works and is simpler.
• Gitea — generate a token under Settings → Applications with repo, admin:public_key, admin:repo_hook scopes. Enter your Gitea URL + the token.

Caution

If GitHub only shows your public repos after connecting, the token is missing Metadata: Read or is scoped to “Only select repositories”. Fix the token’s access + permissions, then reconnect.

What you can do

Once connected, browse your repos. Per repo:

• Create repo — name, description, private/public, auto-init README — one modal
• Clone URLs — SSH + HTTPS shown with one-click copy
• Browse files — a read-only file browser: navigate the tree, view file contents, switch branches (the Files tab on a repo)
• Upload to repo — drag a folder or files in and commit them straight to a branch (see below)
• 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

Upload code to a repo

On a repo’s Files tab, Upload lets you drag a folder (or files) and commit them in one atomic commit — handy for getting an app’s source into a fresh repo, or updating files, without leaving the panel.

Build artifacts are excluded automatically: Mezzanine merges built-in ignores (node_modules/, dist/, build/, .next/, target/, vendor/, *.log, …) with the repo’s .gitignore and the dropped folder’s .gitignore, then shows a preview — “N to commit · M skipped” — before you commit. .git/ is never touched.

Note

Uploads are capped at 9 MB per commit (plenty for a gitignore-filtered source tree). For the initial import of a large existing codebase, do a one-time git push; after that, in-panel uploads for changes work fine.

Closing the CI/CD loop

The deploy-workflow setup is now (almost) one screen. In Deploy → New deploy, the Git source step has a repo picker — choose a connected account, pick a repo, and it fills the clone URL + branch. For a private repo, a one-click Add deploy key button pushes the target server’s key to the repo. Then enable CI/CD on the workflow and add the webhook from the repo’s Webhooks tab, and every push (including in-panel uploads) auto-deploys.

See the Deploy workflows guide for the full end-to-end flow.

All Git mutations require the admin role.