Git accounts
Connect GitHub, GitLab or Bitbucket with an access token so applications can clone your repositories and deploy on push.
An application that deploys from a repository needs to read that repository. Rather than asking for a token every time you create one, OSS Panel stores the token once as a Git account and lets you pick it by name afterwards.
Until an account is connected, Integrations → Git is an empty screen with a three-step summary of what is about to happen.
A public repository needs no account at all — the create form accepts a public clone URL directly. Connect an account for private repositories, and for Deploy on push, which needs permission to add a webhook.
What the panel does with the token
It reads, and it manages one webhook. Specifically:
- lists your repositories and their branches, so the create form can offer them;
- clones the repository and fetches it again on every deploy;
- adds the deploy webhook when you turn on Deploy on push, and removes it again when you turn it off.
It never pushes code, never creates or deletes repositories, and never touches anything outside the repository you choose.
Supported providers
| Provider | Hosted at | Extra field |
|---|---|---|
| GitHub | github.com | — |
| GitLab | gitlab.com, or your own server | Self-hosted URL (optional) |
| Bitbucket | bitbucket.org | Workspace (required) |
Those three are the whole list in v1.0.14. Other Git hosts — Gitea, Forgejo, Codeberg, a bare SSH remote — are not selectable here.
Gitea is a different feature
Gitea and Forgejo appear in OSS Panel as application types you can host on your own server. That is unrelated to this screen: you can run Gitea, but you cannot yet deploy from it through a connected account.
Connect an account
Open Integrations → Git and press Connect account. The dialog asks which provider first — the form that follows differs per provider, so this choice comes before anything else.
Create a token at the provider, with the scopes the dialog names. Each form spells out exactly which boxes to tick and links straight to the right page at the provider.
For GitHub, that is repo and admin:repo_hook. The second is what lets
the panel add the deploy webhook for you.
For GitLab, tick api and read_repository, and choose Legacy token.
The form explains why api is needed — it is the only GitLab permission that
can create a webhook — and offers the lower-access alternative: read_repository
plus read_api, with you adding the webhook by hand.
Leave Self-hosted URL empty for gitlab.com. For your own GitLab, give the
address you sign in at (https://gitlab.example.com), not the address of a
project.
For Bitbucket, tick read:repository:bitbucket, read:webhook:bitbucket,
write:webhook:bitbucket and delete:webhook:bitbucket. Workspace is
required and is the ID from your Bitbucket address —
bitbucket.org/<workspace>/<repository> — not your display name.
Give the account a name and paste the token, then press Connect. The name is only for you; it is how the account appears in the application create form, so "Work GitHub" beats "token 2".
The panel checks the token with the provider before saving it. Nothing is stored if the provider says no.
A rejection almost always means one of three things: the token was truncated on the way over, it is missing a scope from the step above, or it has expired.
Pick the account when you create an application. That is the whole point of the screen — see Deploy from Git.
Token health
Connected accounts are not assumed to keep working. The panel re-checks them and shows one of four states on the account card:
| State | Means |
|---|---|
| Working | The provider accepted the token just now. |
| Not working | The provider rejected it — revoked, deleted or expired. |
| Could not check | The provider did not answer. Nothing is wrong with your token. |
| Not checked yet | Connected, not yet verified. |
GitLab is the only provider that reports an expiry date, so a GitLab account can warn you before it breaks ("Expires in 7 days"). GitHub and Bitbucket tokens simply stop working on the day they lapse.
Check all accounts again on the card header re-runs every check at once.
Account actions
The … menu on an account:
- Check connection — ask the provider about this token now.
- Check repository access — go further and list repositories. This catches a token that is valid but can't see anything, which is the usual result of a GitHub fine-grained token with no repositories selected.
- Edit — rename the account, or correct the workspace or self-hosted URL. The token is not touched.
- Replace token — paste a new token. The new one is verified first; if it is rejected, the old one keeps working.
- Disconnect — remove the account from this server.
Disconnecting does not revoke
Removing an account deletes the panel's copy of the token. The token itself stays valid at GitHub, GitLab or Bitbucket until you delete it there — the dialog links you to the right page. Applications that deployed from the account are not deleted, but they can no longer fetch code until you give them another one.
Limits and caveats
- One token per account. There is no OAuth sign-in flow; everything is a personal access token (or a Bitbucket API token) you create yourself.
- A self-hosted GitLab must be reachable over HTTPS and must not resolve to loopback or to a cloud metadata address. A private LAN address is accepted — a GitLab on the same network is a normal setup.
- Bitbucket is addressed per workspace. An account connected to one workspace cannot see repositories in another; connect a second account for that.
- Account names are unique on a server.
- Everything on this screen needs Git · Manage. With view-only, you can see the accounts and their health but no buttons.