Git providers

Settings -> Git.

There are two ways to connect:

GitHub connects as a GitHub App. You click, approve on GitHub, and Deplo receives the credentials. Nothing to copy. See GitHub.
Everything else connects as a git connection: one stored token per host, reused by every app. This covers GitLab, Bitbucket and Gitea or Forgejo, your own instance included, and is marked Beta. A plain Git connection works for any other server, but has no repository picker, branch list or webhook.

Tokens are encrypted and never returned by the API.

What each connection unlocks

	GitHub App	GitLab, Bitbucket, Gitea	A plain Git connection, or a bare URL
Repository picker	yes	yes	no
Branch list	yes	yes	no
Deploy on push	yes	yes	no
Pull request previews	yes	no	no
Preview comments	yes	no	no

The last column only clones. To deploy automatically, use the deploy hook.

The deploy sources are GitHub, Git, Docker Image, Upload and Compose. GitLab, Bitbucket and Gitea are in a dropdown inside the Git source.

A team can connect more than one GitHub App, one per GitHub owner. This is how a personal account and an organisation live side by side.
GitLab reports token expiry, Gitea does not. For Gitea or Forgejo, a background check tells you when a token stopped working.
A revoked token is reported before a deploy fails, because connections are re-tested in the background.
Webhooks are registered automatically and removed when the app stops using them.
The token is per host, not per repository. Limit its scope on the provider's side.

The repository list is empty: the GitHub App has no access. Use Manage and grant it there.
Authentication failed in a clone: the token expired or was revoked. Test connection confirms it.
Pushes do not deploy: check the webhook status in the app's Settings -> Deployments. The provider must be able to reach this instance.
Saving the address is refused: it resolves to a private address. Only an instance admin can allow that.