GitHub Credential Security#

Overview#

Dokploy stores GitHub App credentials (private key, client secret, webhook secret) in the database for server-side deploy and API operations. A project-wide convention ensures these secrets are never returned to API clients — every read path serving UI or external consumers strips them at the query or serialization layer. Server-side code that needs real credentials re-fetches them directly via dedicated lookup functions.

Two vulnerabilities shaped this convention:

• GHSA-hg9j-j5mc-phf5 / GHSA-wx75-vxph-2m2f — application.one was disclosing git-provider secrets to users with only service:read (fixed in PR #4859)
• Credential leak via gitProvider.getAll — all secret columns were returned in the list response (fixed in PR #4569)

Secret Redaction Patterns#

1. findApplicationById — Query-level exclusion#

findApplicationById in packages/server/src/services/application.ts excludes secret columns from nested provider relations directly in the Drizzle ORM query using columns: { ...: false }:

• GitHub: githubClientSecret, githubPrivateKey, githubWebhookSecret 1
• GitLab: secret, accessToken, refreshToken 2
• Bitbucket: appPassword, apiToken 3
• Gitea: clientSecret, accessToken, refreshToken 4
• Registry passwords use the same pattern: registry, buildRegistry, rollbackRegistry all exclude password 5

Drizzle types the columns option against each table's column list, so a misspelled column name fails tsc — the exclusions are validated at compile time 6.

2. gitProvider.getAll — Response-level allowlisting#

The getAll tRPC procedure fetches full provider objects (credentials are needed to compute derived booleans), then explicitly reconstructs each provider with only safe fields before serializing the response 7:

• GitHub: githubId, githubAppName, githubAppId, githubInstallationId, plus isConfigured (computed from presence of private key / app ID / installation ID)
• GitLab: gitlabId, applicationId, gitlabUrl, plus isConfigured
• Bitbucket: bitbucketId, bitbucketUsername, isConfigured, isDeprecated
• Gitea: giteaId, giteaUrl, clientId, plus isConfigured

The UI consumes these derived isConfigured/isDeprecated flags instead of checking raw credential values directly.

Unredacted Credentials for Deploy & API Operations#

The convention: server-side code that needs real credentials never reads from findApplicationById's result. It calls the dedicated provider lookup functions — findGithubById, findGitlabById, findGiteaById, findBitbucketById — which return unredacted rows directly from the github/gitlab/etc. tables.

Three key flows rely on this:

Repository cloning — cloneGithubRepository calls findGithubById to get the private key, authenticates via authGithub, exchanges for an installation token via getGithubToken, and injects it into the clone URL as https://oauth2:<token>@github.com/<owner>/<repo>.git 8. The token is short-lived (GitHub installation tokens expire after 1 hour) and never logged.

Webhook signature verification — The GitHub webhook endpoint /api/deploy/github fetches the provider record by installationId to verify the HMAC-SHA-256 signature against githubWebhookSecret. This is the only read path for githubWebhookSecret, and it reads directly from the database 9.

Preview deployment PR comments — Functions that post or update Octokit PR comments (issueCommentExists, updateIssueComment, createPreviewDeploymentComment, createSecurityBlockedComment) each call findGithubById independently to obtain credentials at call time, rather than depending on a previously-fetched application object.

Note on createPreviewDeployment: This function calls authGithub(application?.github as Github) where application.github comes from findApplicationById — but githubPrivateKey is excluded in that query. This is a latent inconsistency: authGithub will throw NOT_FOUND at runtime if private key is absent. PR comment operations in the preview flow work around this by re-fetching via findGithubById directly.

Collaborator Permission Gate for Preview Deployments#

To prevent arbitrary PR authors from triggering preview deployments (which execute code and can access server secrets), the webhook handler enforces a per-application permission check 10:

• When previewRequireCollaboratorPermissions !== false (the default), checkUserRepositoryPermissions queries octokit.rest.repos.getCollaboratorPermissionLevel. Only write, maintain, or admin permission levels pass 11.
• Blocked authors receive a security notification comment via createSecurityBlockedComment, with deduplication via hasExistingSecurityComment to avoid repeat comments on subsequent pushes.
• On API error (e.g., 404 from GitHub for non-collaborators), the function returns hasWriteAccess: false rather than throwing, so errors deny-safe 12.

Key Files#