SpipCP Docs

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

A git account is a reusable provider credential connected once and assigned 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.

The token is sent once when the account is connected, stored encrypted, and 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. Fields to 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 it's relied on.

GitHub via OAuth

For GitHub, signing in with OAuth is available 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 connects 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 can be registered on the repo in one click through the account.

The account can always be skipped in favor of pasting 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