Integrations
Credentials that live somewhere else — a Git account, a storage destination, a container registry login — stored once and reused by the features that need them.
Most of OSS Panel manages things that exist on your server: users, sites, databases, firewall rules. Integrations is the opposite — it holds the credentials for services that live somewhere else, so the features on this server can use them.
The sidebar groups them under their own Integrations heading, below the server screens.
| Integration | What it stores | Who uses it |
|---|---|---|
| Git | An access token for GitHub, GitLab or Bitbucket | Applications that deploy from a repository |
| Storage | An S3 bucket, FTP/SFTP server or Google Drive | Application backups |
| Docker Registries | A registry username and access token | Container applications pulling private images |
Each one is connected once and then picked by name wherever it is needed — you never paste a token into an application form.
Permissions
Each integration is its own permission, so you can hand one out without the others. A role with Git · Manage can connect and remove Git accounts but cannot touch storage destinations, and vice versa.
Registry credentials are deliberately not part of the docker permission.
Managing networks and volumes is a job on this box; storing a registry login is
storing a key that can pull private code onto it.
Permissions are set per role under Administration. A role without view on an integration does not see it in the sidebar at all.
What is not here
Two things that look like integrations are not in this section:
- Deploy webhooks. The panel registers these on your repository for you when you turn on Deploy on push for an application — see Deploy from Git.
- SSH keys. Keys that let a person into this server belong to a system user, under System users.