Gitea-linked Compose app silently fails to create the repo webhook (no error, no retry, no repair)

[lamualfa]

Summary

Linking a Gitea repository to a Compose application (sourceType: gitea, Auto Deploy enabled) does not reliably create the corresponding repo webhook in Gitea. When this happens the failure is silent — there is no error in the Dokploy logs, no retry, and no way to detect or repair it from the UI. Pushes to the repo then never reach Dokploy.

Environment

• Dokploy: v0.29.8 (Docker)
• Gitea: 1.26.2
• Source type: Compose → Gitea (OAuth provider), Auto Deploy = on, Trigger = push

Symptom

On a single Dokploy instance I have 3 Compose apps with sourceType=gitea, autoDeploy=true, identical config (giteaOwner/giteaRepository/giteaBranch set, valid giteaId, valid refreshToken). Created within the last ~10 days.

Querying the Gitea webhook table, only 1 of the 3 repos has a webhook pointing at Dokploy's deploy endpoint:

webhook_id | repo                  | url                                                    | is_active
         3 | lamualfa/centerbuild  | http://<host>:3000/api/deploy/compose/<refreshToken-A> | t

The other two repos (one created today, one ~9 days ago) have no webhook at all — not repo-level, not org-level, not system-level. So git push to those repos lands in Gitea (the internal post-receive hook fires) but nothing is delivered to Dokploy.

For the one repo that does have its webhook, the chain works perfectly — Gitea webhook delivery timestamps map 1:1 to Dokploy deployment rows with status=done. So the deploy side is fine; the problem is the webhook never getting created for the other repos.

Evidence that it's silent

$ docker logs --since 168h dokploy | grep -ic webhook
0

Zero webhook-related log lines over the last 7 days, and zero errors. The missing-webhook condition produces no signal anywhere I could find.

Expected

• Creating/validating the repo webhook is part of "connect a Gitea source" (per the docs: "the webhook is automatically configured when you connect the repository"). If the creation API call fails (e.g. token state at connect time), Dokploy should:
  • surface the error, and
  • retry, or at least expose a "Repair webhook" / "Re-create webhook" action per Compose app.

Actual

• Webhook creation silently no-ops for some repos.
• No error is logged.
• No retry, no reconciliation, no repair button.
• The only fix is to manually create the webhook in Gitea (URL …/api/deploy/compose/<refreshToken>, push events, branch filter) or patch the Gitea DB directly.

Reproduction

1. Stand up Dokploy + a Gitea instance. Connect a Gitea provider (OAuth).
2. Create a Compose app, source = Gitea, pick a repo/branch, enable Auto Deploy, deploy once.
3. Check the Gitea repo's webhooks (UI or GET /api/v1/repos/{owner}/{repo}/hooks).
4. Repeat for several repos. Observe that some repos end up with no Dokploy webhook.

(I can reproduce the missing state, though I haven't isolated which connect-time condition triggers it — possibly OAuth token freshness at the moment the source is linked. Either way, the absence of detection/repair is the core issue.)

Workaround

A reconciliation script that enumerates Dokploy compose apps (sourceType=gitea, autoDeploy=true), derives the expected webhook URL (<dokploy>/api/deploy/compose/<refreshToken>), finds the matching Gitea repo, and creates the webhook if missing. Happy to share if useful.

Related

This lines up with the "Webhook & auto-deploy: a persistent pain point" theme noted in the project's own issues docs, and is adjacent to #4019 (orphan containers on project-name change), which I also hit here.

---

Thanks for the project — happy to provide more detail or test a fix.

[dosubot]

@lamualfa — this is the same root cause you identified and filed a fix for in #4413. To confirm for anyone following along:

Dokploy does not currently implement automatic webhook creation for Gitea repositories [1]. Unlike the GitHub integration, the Gitea service layer (packages/server/src/services/gitea.ts) has no webhook creation logic — it only has basic CRUD operations. The OAuth scopes also only request read-level permissions, which wouldn't allow webhook creation even if the logic existed [2].

Your PR #4413 addresses both parts of this (scope fix + createGiteaWebhook() utility) but is still open and unmerged [3]. A similar effort for GitLab is also in progress via PR #4608 [4].

So this issue is effectively a duplicate of — or at minimum fully covered by — the work in #4413. The "silent failure" framing is accurate: since the auto-creation logic doesn't exist yet, there's nothing to fail or log; it simply never attempts to create the webhook in the first place.

For anyone hitting this in the meantime, the workaround from the earlier discussion [5] still applies: manually create the webhook in Gitea with URL {dokploy-url}/api/deploy/compose/{refreshToken}, content type application/json, trigger on push events. If Gitea and Dokploy share the same Docker host, use the internal Docker IP and add the subnet to Gitea's [webhook] ALLOWED_HOST_LIST.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.