Feature Request: native Tailscale integration — `tailscale cert` HTTPS + tailnet hostname awareness

What problem will this feature address?

I run Dokploy in a Debian VM with Tailscale as the access plane. The manual setup works but is rough at the edges — Dokploy treats Tailscale-only deployments as misconfigured, and per-app HTTPS over the tailnet is entirely manual.

Concrete pain points today:

1. Per-app cert management is manual. Every new app domain → sudo tailscale cert <host> → paste cert + key into Dokploy's "Custom Certificate" UI. I run a systemd timer + small renewal script on the host to keep certs fresh and SIGHUP Traefik. New apps repeat the whole sequence.
2. Tailnet identity isn't auto-detected. The Domain config UI shows a red Domain resolves to <tailnet-IP> but should point to <WAN-IP> warning for tailnet-only domains, treating tailnet IPs as a misconfiguration when they're actually the correct routing target. Same WAN-IP bias surfaces at install time, where the installer prints the public WAN IP (from curl ifconfig.me) as the go-here URL even on tailnet-only hosts — a user who pastes that into a port-forward rule has just exposed admin to the public internet.
3. No "deploy and expose on tailnet" one-click flow. Spin up a new app → admin still has to: register the tailnet domain, generate the cert, paste it in, edit a renewal script. 4–5 manual steps when the operator has already chosen Tailscale as the access plane.

Describe the solution you'd like

Smallest useful chunk first; everything else is optional follow-up:

• Settings → Server → Tailscale section — detected tailnet name, hostname, auth status. Stops the WAN-IP-bias warnings on tailnet domains by recognizing the host's own tailnet identity.
• "Use Tailscale-issued cert" toggle on per-domain config — Dokploy runs tailscale cert <host> and schedules renewal automatically (the cert is on a 90-day rotation; renewal is the part most users will skip and silently break).
• (Optional, harder) Per-app Tailscale sidecar mode — each app gets its own tailnet identity (<app>.<tailnet>.ts.net) for ACL-aware access, similar in shape to tsdproxy.

The cert-toggle alone closes ~80% of the rough edges.

Describe alternatives you've considered

• tsdproxy — auto-creates per-container tailnet endpoints via Docker labels (sidecar pattern). Solves the per-app Tailscale identity problem cleanly but is a separate proxy layer, doesn't compose with Dokploy's existing Traefik or domain UI. Reasonable reference for the API shape if a sidecar mode is pursued.
• Manual tailscale cert + Custom Certificate UI (today's status quo) — works but is the source of all the pain points above.
• Public DNS + Let's Encrypt HTTP-01 — doesn't apply for tailnet-only deployments since the hostname doesn't resolve from the public internet.
• Reverse-proxying through a Tailscale Funnel — exposes the service to the public internet, defeating the point of using a tailnet for access control.

Additional context

Tailscale HTTPS docs — the underlying primitives that the cert-toggle would wrap.

Will you send a PR to implement it?

Maybe, need help

Review the Settings → Server flow, the per-domain Custom Certificate UI, and the installer’s WAN-IP URL behavior before choosing an implementation boundary. Done should include a focused Tailscale integration that recognizes tailnet identity and supports the requested certificate-toggle flow, with renewal handled rather than left manual.