Deployment sources

A deployment source connects a boundary to a Git provider or a private container registry. Resources in that boundary can then build from its repositories or pull its images; resources in other boundaries cannot use it.

Deployment sources live on the boundary: open Settings → Boundaries in the sidebar, pick the boundary, and open its Deployment Sources tab.

Action	Allows	Held by
kernel/deployments/read	See the boundary's sources	Owner, Contributor; Apps Reader, Apps Operator, Functions Operator, Blueprints Operator
kernel/deployments/write	Connect a source	Owner, Contributor
kernel/deployments/delete	Delete a source	Owner, Contributor

Add a source

Choose Add Source and pick the provider. The wizards of App Service and Static Web Apps also offer Connect Deployment Source, but connecting GitLab or Azure DevOps with an OAuth application leaves the page you are on — connect those from the boundary before you start a wizard.

GitHub

1. Optionally enter a GitHub Organization to connect an organization rather than your personal account. You must be signed in to GitHub, and for an organization be one of its owners.
2. Choose Continue to GitHub. GitHub opens in a new tab and creates a private GitHub App for this boundary.
3. Install the app and choose, on GitHub, whether it may reach all repositories or only selected ones.

The app can read the repositories' contents and receives their push and pull request events.

GitLab

Choose OAuth App or Access Token, and fill in Base URL with your GitLab's address — for example https://gitlab.com, or https://gitlab.yourcompany.com for a self-hosted GitLab. Left empty, the platform uses the GitLab address configured for your installation.

• Access Token — enter an Access Token with the api and read_repository scopes and choose Connect with Token. A group or project access token needs the Maintainer role.
• OAuth App — first register an OAuth application in GitLab with the redirect URI https://api.example.com/sources/gitlab/validate and the scopes api and read_repository. Enter its Application ID and Application Secret, choose Connect to GitLab and approve the request in GitLab.

The source reaches the projects the credential's user is a member of.

Azure DevOps

Choose OAuth App or Personal Access Token.

• Personal Access Token — enter the Organization URL, exactly https://dev.azure.com/<organization>, and a Personal Access Token with at least the Code (Read) scope, and choose Connect with Token. Azure DevOps Server is not supported.
• OAuth App — first create an app registration in Microsoft Entra ID with the redirect URI https://api.example.com/sources/azure-devops/validate. Enter its Application ID, Application Secret and Tenant ID, and choose Connect to Azure DevOps. Leave Tenant ID empty only if your platform administrator has configured a default tenant. The source uses the first organization your Microsoft account belongs to.

The source reaches every repository in the organization.

For pushes to deploy, the Azure DevOps user behind the token or the sign-in also needs the Edit subscriptions and View subscriptions permissions for service hooks in each project the platform builds from; by default only project administrators have them. Without them the source connects and builds, but the platform cannot register its service hooks, so pushes never start a build.

Private registry

1. Choose Private registry.
2. Registry — the host only, for example ghcr.io, not a URL. Leave it empty for Docker Hub.
3. Username and Password or token. The password is stored encrypted and never shown again.
4. Choose Connect registry.

A boundary has one credential per registry host. To change the password, connect the same registry again: the new credential replaces the old one. Containers that are already running keep using the previous credential until they are redeployed.

View a source

Choose a source in the list to see its status, repository access, installation ID and the repositories it can reach. For GitLab sources, Token Health shows whether the credential is Healthy, Expiring Soon (less than 14 days left), Expired or Revoked; it is checked once a day.

Delete a source

Use the delete action on the source's row and type its installation ID to confirm. For a private registry the installation ID is the host written with hyphens, for example ghcr-io.

Deleting revokes what the platform can revoke — the GitHub App's installation, GitLab OAuth tokens — and removes the credential from the platform. It does not clean up on the provider's side: the GitHub App itself, and the webhooks the platform added to GitLab projects and Azure DevOps, stay until you remove them there. Resources that build from the source can no longer build.

Use a source

Where	What it uses
App Service — create wizard, step Deployment Source — see Create an app	A GitHub, GitLab or Azure DevOps repository and branch. The Container option takes a public image; apps cannot pull from a private registry.
Static Web Apps — create wizard, step Source — see Create a static web app	A GitHub, GitLab or Azure DevOps repository and branch
Container Instances — step Image — see Choose the image	An image from a private registry
Blueprints — a parameter of type DeploymentSource	A private registry
Blueprint catalog sources — see Add a catalog source	A GitHub, GitLab or Azure DevOps repository holding blueprints

Functions do not use deployment sources. An app or static web app can switch provider, repository or branch later under Configuration → Deployment Source.

Automatic deployments

A push to a connected repository rebuilds, at the pushed commit, every app built from that repository whose branch — or one of whose slots' branch — matches, and every static web app built from that repository and branch. For an app, the push also replaces a version you pinned with Redeploy this version. There is nothing to switch on: the platform registers the webhook itself — for GitHub as part of the GitHub App, for GitLab and Azure DevOps on the project when it builds from it.

If pushes never start a build, check that the credential may create webhooks — for GitLab, the Maintainer role on the project; for Azure DevOps, the service hook permissions above. Otherwise deploy by hand and ask your platform administrator to check the platform's settings for that provider.

Manual deployments

• App Service: Deploy, or Re-deploy, on the app or a slot — needs apps/write.
• Static Web Apps: Deploy — needs staticwebapp/deploy.
• Container Instances: Re-deploy on a component — needs containerinstance/write.