The Deployer documentation
Connecting your accounts

Connect GitLab or Bitbucket

Your code doesn't have to live on GitHub — The Deployer works the same way with GitLab and Bitbucket. You connect an account with one click, or with an access token, pick a repository when creating a project, and everything else (scanning, deploying, push-to-deploy) behaves identically. GitLab.com and Bitbucket Cloud are supported; self-managed GitLab and Bitbucket Server/Data Center are not.

Current access model. Either host gives The Deployer access across the repositories your account can reach, not only the one you deploy. With the buttons below you approve that on the host, and The Deployer keeps a short-lived key it renews by itself. With a token you create it yourself: set an expiry where the host allows it, use one made only for The Deployer, and see Permissions & security.

The quickest way: the Connect buttons

  1. Open Connections from the left sidebar.
  2. Under Git accounts, click Add account, then Connect with GitLab or Connect with Bitbucket. (The same page also has Connect with GitHub.)
  3. The host shows what The Deployer is asking for: your repositories, including private ones, their push-to-deploy webhooks, and your account name. Click Allow (GitLab) or Grant access (Bitbucket).
  4. You come back to Connections, where the new card shows verified and your username.

The host's key lasts about two hours and The Deployer renews it before anything uses it, so you never paste or rotate anything. If the host ever stops honouring it, for example because you removed The Deployer from the host's list of authorized applications, the card turns to error: click the refresh icon on it (Reconnect) and approve again. Deleting the connection in The Deployer also ends the access on GitLab; on Bitbucket, remove The Deployer under Settings → OAuth if you want it gone there too.

Don't see the Connect buttons, or want a key you control? Use an access token, as described next.

Connect GitLab with a token

You'll create a Personal Access Token with the api scope. That one scope lets The Deployer read your repositories and branches, commit readiness fixes you approve, and register the push-to-deploy webhook.

  1. Go to gitlab.com, click your avatar (top-left) → Edit profile → Access tokens.
  2. Click Add new token. Name it something you'll recognize, e.g. The Deployer, and pick an expiry date.
  3. Under Select scopes, tick api.
  4. Click Create personal access token and copy the token (it starts with glpat- and is shown only once).
  5. In The Deployer, open Connections → Git accounts → Add account, choose GitLab, paste the token, and click Connect & verify.

On success the card shows a verified badge and your GitLab username.

Connect Bitbucket with a token

Bitbucket offers a couple of credential types; The Deployer supports the common ones:

  • App password (or an Atlassian API token): create it, then enter it together with your Bitbucket username (for Atlassian API tokens, use your Atlassian account email) in the connection form.
  • Access token (workspace, project or repository scoped): paste just the token and leave the username field empty.

To create an app password:

  1. Go to bitbucket.org, click your avatar → Personal Bitbucket settings → App passwords.
  2. Click Create app password, name it The Deployer, and tick: Account: Read, Repositories: Read & Write, and Webhooks: Read & Write.
  3. Copy the password (shown once).
  4. In The Deployer, open Connections → Git accounts → Add account, choose Bitbucket, paste the password, enter your username, and click Connect & verify.

Repositories: Write lets the readiness agent commit the fixes you approve (a Dockerfile, a health endpoint) to your branch. Webhooks lets pushes trigger automatic re-deploys.

Everything else works the same

Whichever host you choose:

  • Project creation lists your repositories and branches from that account.
  • Push-to-deploy is wired automatically: a webhook on your repository tells The Deployer about every push to the tracked branch, and a polling fallback covers setups where webhooks can't reach the backend. Pushes deploy on the Pro and Team plans; on Free, use Pull & Restart.
  • Tokens are encrypted at rest, used by the deployment engine rather than placed in AI prompts, and can be viewed or replaced from the connection card — see Viewing & replacing your credentials.