Deployment source settings

Boundary owners connect deployment sources themselves — see Deployment sources. A few settings of the platform API decide whether those connections and their webhooks can work. They are environment variables of the platform API; the installer sets the first four.

Settings

Setting	Installer sets it to	Used for
Deployments__GitHub__ApiBaseUrl	https://api.example.com	The GitHub App's callback and webhook addresses
Deployments__GitLab__ApiBaseUrl	https://api.example.com	The GitLab OAuth redirect URI and project webhooks
Deployments__AzureDevOps__ApiBaseUrl	https://api.example.com	The Azure DevOps OAuth redirect URI and service hooks
Deployments__FrontendUrl	https://portal.example.com	Where users return to after connecting a source
Deployments__GitLab__BaseUrl	—	The GitLab used when a user leaves Base URL empty. The platform image's default is not gitlab.com; set it to the GitLab your users connect to
Deployments__AzureDevOps__TenantId	—	The Entra ID tenant used when a user leaves Tenant ID empty. Unset, an Azure DevOps OAuth connection without a tenant ID is refused

The platform image's built-in values for the ApiBaseUrl settings point at localhost, so an installation that does not set them gets callback and webhook addresses no Git host can reach. When one is set to an empty value, connecting GitHub, or GitLab or Azure DevOps with an OAuth application, fails, and builds go ahead without registering webhooks — the platform API logs a warning that it skipped them.

Fixed addresses

Address	What calls it
https://api.example.com/sources/gitlab/validate	GitLab, returning a user who approved an OAuth application
https://api.example.com/sources/azure-devops/validate	Microsoft Entra ID, returning a user who approved an app registration
https://api.example.com/boundaries/<boundary-id>/sources/<provider>/webhooks	The Git provider, delivering push and pull request events

Users register the two callback addresses in their OAuth applications. The webhook address is registered by the platform itself. It takes no sign-in: each delivery is authenticated with the source's own secret — GitHub's signature, GitLab's token header, and for Azure DevOps HTTP Basic authentication with the user name stackship and the secret as the password.

When pushes do not deploy

• The Git host must reach https://api.example.com over HTTPS, with a certificate it trusts.
• The credential must be allowed to create webhooks: a GitLab token needs the Maintainer role on the project.
• For Azure DevOps, the user behind the token or the sign-in needs the Edit subscriptions and View subscriptions permissions for the project's service hooks, which by default only project administrators have.
• A webhook the platform cannot create does not stop the build or show on the source: the platform API logs a warning and builds anyway. Look for those warnings when a source builds but never deploys on push.
• A GitHub App keeps the webhook address it was created with. If the API's address changes, existing GitHub sources must be connected again.
• GitLab and Azure DevOps webhooks are created when the platform builds from the project, so a source that has never been built from has none yet.