SpipCP Docs

Connect a provider account once (Forgejo, Codeberg, Gitea, GitLab, GitHub, or Bitbucket) to browse your repos and branches and register deploy keys — without that token ever reaching a node.

A git account is a reusable provider credential you connect once and assign to many sites. It turns the git-deploy flow from "paste a clone URL and register a key by hand" into "connect GitHub, pick a repo, pick a branch." It's a convenience on top of the deploy-key flow — not a replacement for it.

The security stance (read this first)

A provider token NEVER reaches a node

A git account's token lives only in the panel, encrypted at rest, and is used only for panel-side calls to the provider's API — list repos, list branches, register a deploy key. The credential a node uses to git fetch is still the per-site, read-only deploy key. A breached node still exposes exactly one repo, read-only — the git account changes the experience, not the blast radius.

You send the token when you connect the account, it's stored encrypted, and it's never returned to a browser again. The account list shows only the safe fields — provider, label, login, and state.

Connecting an account

Settings → Git accounts → Connect account. You provide:

Field	Meaning
Provider	Forgejo, Codeberg, Gitea, GitLab, GitHub, or Bitbucket. Forgejo/Codeberg use the Gitea API; the open providers are listed first (see Recommendations).
Label	A friendly name to tell accounts apart (`work-forgejo`, `client-gitlab`).
Token	A personal access token with repo + deploy-key scope. Encrypted on arrival; never shown again.
API base URL	Required for self-hosted Forgejo/Gitea (e.g. `https://forge.acme.com/api/v1`). Codeberg defaults to `codeberg.org`; for GitLab/Bitbucket leave it blank.

Test connection checks the token against the provider before you rely on it.

GitHub via OAuth

For GitHub you can sign in with OAuth instead of pasting a token — the panel completes the sign-in and stores the resulting token the same encrypted way. Same security stance: the token stays in the panel and never reaches a node.

Using an account on a site

On a site's Deploys tab, the Source card lets you connect a repo through an account:

Pick a git account → the panel lists its repos.
Pick a repo, then a branch — the branch dropdown is filled from the account, so choosing which branch to deploy is just the selector.
The site's git source is set; the node still fetches with the per-site deploy key, which you can register on the repo in one click through the account.

You can always skip the account and paste a clone URL by hand — the account is a convenience, not a requirement.

Defaults that cascade

A git account can be set as a default so new sites inherit it rather than picking one every time. The default cascades like other fleet settings — a node default flows to its instances, an instance default flows to its sites — and any level can override the one above it. The per-node/instance default lives on its Git tab; the panel-wide default lives here under Settings.

Permissions

Connecting, testing, and revoking accounts needs the git-accounts manage permission; merely listing them (so the connect dialog can offer them) needs the view permission. The server enforces this regardless of what the UI shows.

Next steps

Git deploys — the deploy pipeline the account feeds into.
Deploy from GitHub — push-triggered redeploys via webhooks.
Environment editor — manage a site's .env alongside its deploys.

Git accounts