Gitea webhooks never created — OAuth scopes missing write:repository
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 37.4k
- Forks
- 3k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 73
Description
To Reproduce
- Set up a self-hosted Gitea instance
- Add Gitea as a Git Provider in Dokploy via OAuth application
- Create a Compose project linked to a Gitea repository, enable "Auto Deploy"
- Push a commit to the Gitea repo
- No deployment is triggered — checking Gitea's database shows the
webhookandhook_tasktables are completely empty
Current vs. Expected behavior
Current: Dokploy never creates webhooks in Gitea. Pushing to a Gitea-linked repo does not trigger any deployment. The Gitea database tables webhook and hook_task remain empty.
Expected: Dokploy should automatically create a webhook in the Gitea repository when a Gitea-linked compose/application is saved with auto-deploy enabled. Push events should trigger deployments.
Root cause: The Gitea OAuth scopes across the codebase only request read permissions. Creating webhooks via POST /api/v1/repos/{owner}/{repo}/hooks requires the write:repository scope. The API call fails with:
token does not have at least one required scope, required=[write:repository], token scope=read:organization,read:repository,read:user
Since Dokploy silently fails to create the webhook, the user never gets any error feedback — deployments just never trigger.
Provide environment information
Operating System:
OS: Ubuntu
Arch: x86_64
Dokploy version: v0.29.4
Gitea version: 1.24.4
VPS Provider: Self-hosted
Applications: Docker Compose (Gitea-linked)
Which area(s) are affected?
- Application
- Docker Compose
Are you deploying the applications where Dokploy is installed or on a remote server?
Same server where Dokploy is installed
Additional context
Additional setup issues for self-hosted Gitea + Dokploy on the same Docker host
Even after manually creating the webhook (as a workaround), two more issues surfaced:
-
Internal DNS resolution: Gitea's container could not resolve Dokploy's external domain. Had to use the Docker internal IP as the webhook target URL and add the internal subnet to Gitea's
webhook.ALLOWED_HOST_LISTconfig (SSRF protection blocks private IPs by default). It would be helpful if Dokploy supported an internal callback URL for webhooks (similar to the existinggiteaInternalUrlfield used for clone operations). -
Compose webhook endpoint: The correct webhook path for compose deployments is
/api/deploy/compose/{refreshToken}, not/api/deploy/{refreshToken}. If/when Dokploy auto-creates Gitea webhooks, it must use the correct endpoint based on whether the resource is an application or a compose.
Suggested fix
The scope needs to include write:repository in three files:
1. apps/dokploy/pages/api/providers/gitea/authorize.ts — line 37:
- authorizationUrl.searchParams.append("scope", "read:user repo");
+ authorizationUrl.searchParams.append("scope", "read:user repo write:repository");
2. apps/dokploy/utils/gitea-utils.ts — line 29:
- const scopes = "read:repository read:user read:organization";
+ const scopes = "read:repository write:repository read:user read:organization";
3. packages/server/src/db/schema/gitea.ts — line 24:
- scopes: text("scopes").default("repo,repo:status,read:user,read:org"),
+ scopes: text("scopes").default("repo,repo:status,read:user,read:org,write:repository"),
After fixing the scopes, Dokploy also needs webhook creation logic (similar to what the GitHub integration does). When a Gitea-linked application or compose is saved/updated with auto-deploy enabled, Dokploy should call the Gitea API:
POST {giteaUrl}/api/v1/repos/{owner}/{repo}/hooks
With body:
{
"active": true,
"config": {
"content_type": "json",
"url": "{dokployUrl}/api/deploy/{refreshToken}"
},
"events": ["push"],
"type": "gitea"
}
Using the correct endpoint path:
- For applications:
/api/deploy/{refreshToken} - For compose:
/api/deploy/compose/{refreshToken}
And if giteaInternalUrl is configured, prefer that for the webhook target URL to avoid DNS resolution issues when Gitea and Dokploy run on the same Docker host.
Will you send a PR to fix it?
No
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with apps/dokploy/pages/api/providers/gitea/authorize.ts, apps/dokploy/utils/gitea-utils.ts, and packages/server/src/db/schema/gitea.ts to trace the OAuth scopes and stored defaults. Compare the Gitea flow with the GitHub webhook integration, including application versus compose endpoints and giteaInternalUrl. Done means Gitea-linked resources with auto-deploy create the correct push webhook and deployments trigger successfully.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, backend, devops
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100