Git Provider Configuration#

Overview#

Git provider configuration in Dokploy links an application or Compose stack to a source repository hosted on GitHub, GitLab, Gitea, or Bitbucket. Each provider has a dedicated frontend form component and a matching tRPC mutation that persists the configuration. The UI lives under the General tab of an application or compose service.

Component Structure#

Each git provider has parallel form components — one for Applications and one for Compose stacks:

All components follow the same pattern 1:

1. Fetch registered provider accounts via a provider-specific query (e.g., api.github.githubProviders)
2. Derive available repositories and branches lazily from the selected account
3. Hydrate form state from the persisted application/compose record on mount via useEffect + form.reset
4. Submit via a provider-specific tRPC mutation on save

Form Fields (GitHub)#

The GithubProviderSchema defines the validated fields for an application:

The Compose variant uses composePath (default "./docker-compose.yml") instead of buildPath 2.

Watch Paths#

Watch paths are visible only when triggerType is "push" 3. When a webhook fires for a push, the deployment is triggered only if changed files match one of the configured glob patterns (e.g., src/**, dist/*.js). Paths are stored as a string[] and can be added by pressing Enter or the + button.

The same field is present on all four providers 4 5 6.

Persistence — tRPC Mutations#

All mutations live in apps/dokploy/server/api/routers/application.ts:

Each mutation:

1. Calls checkServicePermissionAndAccess for authorization
2. Updates the application record via updateApplication with sourceType set to the provider name and applicationStatus reset to "idle"
3. Writes an audit log entry

The input schemas (apiSaveGithubProvider, apiSaveGitlabProvider, etc.) are co-located in packages/server/src/db/schema/application.ts.

Permission Check: canEditDeployGitSource#

Before allowing a user to change the git source of an existing deploy, the server calls canEditDeployGitSource from packages/server/src/services/git-provider.ts. It returns true if the user is an org owner, or if the member owns the provider or the provider is shared org-wide 11. This is distinct from the permission to trigger deploys.

Key Behavioral Notes#

• Cascading reset: Selecting a new GitHub account clears the repository and branch fields 12; selecting a new repository clears the branch 13.
• Lazy queries: Repository and branch lists are fetched only after their upstream dependency is set — enabled: !!githubId for repositories, enabled: !!owner && !!repo && !!githubId for branches 14.
• triggerType (push vs. tag) is exposed only on GitHub; GitLab, Gitea, and Bitbucket do not include it in their schemas 15.
• Submodule support (enableSubmodules) is consistently available across all four providers.