Tailscale, let's encrypt and github webhooks

[visiongeist]

Hi,
when I take down the dokploy UI to be reachable from public and only having access to it through tailscale, how do I make sure that github webhooks and also the ootb let's encrypt cert. assignment is still working?
thank you

[dosubot[bot]]

Hi @visiongeist! I'm Dosu and I'm helping the Dokploy team.

Both concerns come from the same root: Dokploy's ACME setup uses an HTTP-01 challenge — Traefik's letsencrypt resolver issues challenges on the web (port 80) entrypoint [1]. That means Let's Encrypt must reach http://your-domain/.well-known/acme-challenge/... from the public internet. If your server isn't publicly reachable on port 80, certificate issuance will fail [2].

Similarly, GitHub webhooks hit POST /api/deploy/github on your server's public URL [3], so GitHub's servers also need to reach your host.

The practical approach: Keep ports 80 and 443 publicly open at the firewall level, but restrict access to the Dokploy UI specifically via Tailscale or Traefik middleware. The Dokploy UI uses the Traefik router dokploy-router-app [4], so you can add authentication middleware (e.g., basicAuth, ipAllowList, or forwardAuth) to that router only, leaving the webhook path /api/deploy/github and ACME challenge paths accessible. Traefik supports per-router middleware, so you can be selective about what's protected.

Alternatives for Let's Encrypt if you can't open port 80:

• DNS-01 challenge — doesn't require any inbound connection. Traefik supports it via DNS provider plugins (Cloudflare, Route53, etc.), but you'd need to configure this manually in Traefik's static config since Dokploy doesn't expose a DNS-01 option in the UI [1].

Alternatives for GitHub webhooks if you can't expose the endpoint:

• Tailscale Funnel — if available on your Tailscale plan, it can expose specific paths publicly through Tailscale's relay infrastructure without opening your firewall directly (note: this is a Tailscale feature, not Dokploy-specific).
• A webhook relay/proxy (e.g., smee.io) that forwards events to your private endpoint — though this adds operational complexity.

In short, the simplest path is keeping 80/443 open while locking down the UI router specifically, rather than hiding the entire server behind Tailscale.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[jmrplens]

The two halves have different answers, and the certificate one goes away completely.

Certificates. The default resolver is HTTP-01 on the web entrypoint (packages/server/src/setup/traefik-setup.ts hardcodes httpChallenge: { entryPoint: "web" }), and HTTP-01 can only be validated on public port 80, which is why taking the host off the internet breaks it. DNS-01 has no such requirement and Dokploy's own Traefik types already model it: dnsChallenge with provider, delayBeforeCheck and resolvers in packages/server/src/utils/traefik/types.ts. Swap the resolver in /etc/dokploy/traefik/traefik.yml (bind-mounted into the container as /etc/traefik/traefik.yml), pass your DNS provider credentials to the Traefik container, and port 80 stops mattering for certificates entirely, renewals included.

The edit survives restarts. createDefaultTraefikConfig returns early when the file is already there (if (stats.isFile()) { ...; return; }), so it is not regenerated over you.

I ran this before suggesting it: Traefik v3.6.25, which is the version Dokploy pins, with that config shape and port 80 never published at all. It issued and served the certificate. One thing that did stall me: lego checks the zone's authoritative nameservers before asking for validation, so if your provider is slow to propagate look at propagation.delayBeforeChecks, and propagation.disableANSChecks if the zone does not answer NS queries the way lego expects.

Webhooks. GitHub does have to reach you, but not through your domain or your firewall. Tailscale Funnel publishes a single path without opening a port:

tailscale funnel --set-path=/api/deploy/github 3000

then set the webhook URL to the resulting ts.net address. Funnel only listens on 443, 8443 and 10000, so pick accordingly.

If you would rather keep 443 open instead, at least scope it. GitHub publishes its webhook source ranges in the hooks array of https://api.github.com/meta, six CIDRs today. Allowlist those on that path only, and refresh from the API rather than pasting them once, because they do change.

Worth noting the reply above leaves 80 and 443 publicly open and protects only the UI. That works, but it keeps the host reachable from the internet, which is the thing you were trying to stop.

[orlandoflv]

Hi @jmrplens , I'm having the same issues as @visiongeist so I decided to follow your instructions. The problem with the certificates dissapeared once i changed to dnsChallenge. However when I try to use a funnel tailscale funnel --set-path=/api/deploy/github 3000 and adapt the webhook url to use the machine.ts.net address, it looks like github is delivering the payload but actually the response body from dokploy is just the html body of the login page. It looks like the ts.net address is being redirected to the login page instead of to the actual api endpoint (/api/deploy/github). Do you have any insight of what could I be doing wrong? Thanks

[jmrplens]

Glad the certificate half is sorted. The webhook one is the funnel path mount doing what it is built to do, not Dokploy.

tailscale funnel --set-path=/api/deploy/github 3000 mounts the target at that path and strips the mount point before proxying, so what reaches Dokploy is /, and / is the login page you are getting back. It is explicit in ipn/ipnlocal/serve.go:

// Trim the mount point from the URL path before proxying. (#6571)
if r.URL.Path != "/" {
	h = http.StripPrefix(strings.TrimSuffix(mountPoint, "/"), h)
}

GitHub records the delivery as successful because the funnel does answer: 200, with that HTML as the body.

Put the path on the target as well, so what the mount point strips the target puts back:

tailscale funnel --set-path=/api/deploy/github http://127.0.0.1:3000/api/deploy/github

That exact case is handled on purpose in the same file: when the incoming path equals the mount point, the stripped path is empty and the outbound path is set to the target's path instead of the target plus a slash.

I do not have a tailnet here to try a real funnel, so I reproduced the two configurations with the same handler chain the code uses, StripPrefix in front of a reverse proxy, and printed the path the upstream sees:

target given to funnel	path Dokploy receives
3000	/
http://127.0.0.1:3000/api/deploy/github	/api/deploy/github

The other way out is tailscale funnel 3000 and pointing the webhook at https://machine.ts.net/api/deploy/github, which works because nothing is mounted on a subpath. I would stay with the path scoped one though: funnelling the whole port puts the entire Dokploy UI and its login on the public internet, while the path mount exposes only the deploy endpoint.

[orlandoflv]

Thanks a lot for your detailed answer! I chose the scoped path configuration, and that worked as described. I'm sure your answer will help some people.