Use Tailscale MagicDNS subdomain resolution for worktree-specific hostnames

Context

Tailscale just merged #1196 / PR #18258 adding wildcard subdomain resolution to MagicDNS. A new dns-subdomain-resolve node capability makes *.machine.tailnet.ts.net resolve to the machine's IP.

This opens up a nice approach for dev environments: instead of assigning different port ranges per worktree to avoid conflicts, each worktree gets a unique subdomain and services can bind to standard ports.

Current state

• Ports are allocated via ports.http.allocate with automatic fallback (e.g. Storybook on 6006-6012)
• No Tailscale integration in devenv currently
• Multiple worktrees running simultaneously need distinct ports to avoid conflicts

Proposed approach

With dns-subdomain-resolve enabled on a dev machine, each worktree could get a hostname derived from its directory name:

toronto-v1.schickling-dev.tailnet.ts.net  →  worktree 1
paris-v1.schickling-dev.tailnet.ts.net    →  worktree 2

A local reverse proxy (e.g. Caddy) would inspect the Host header and route to the correct worktree's services. All worktrees could bind to the same standard ports since the subdomain disambiguates.

What this enables

• No more port conflicts between worktrees
• Stable, memorable URLs per worktree (shareable with teammates on the same tailnet)
• Multi-tenant apps can use subdomains naturally during development
• Each service gets its own browser security context (unlike path-based routing)

Rough devenv integration sketch

In devenv.nix:

• Derive subdomain from worktree directory name (e.g. toronto-v1)
• Start a Caddy/nginx reverse proxy mapping <worktree>.machine.tailnet.ts.net → local services
• Export DEV_HOST=<worktree>.machine.tailnet.ts.net for apps to reference
• ACL config: { "nodeAttrs": [{ "target": ["tag:devbox"], "attr": ["dns-subdomain-resolve"] }] }

Blockers / open questions

• Not released yet — merged to main on Jan 30, 2026 but latest release (v1.94.1) predates it. Need to wait for next release (~v1.96+)
• No wildcard TLS certs — tracked in tailscale#7081. Options: plain HTTP over WireGuard tunnel (already encrypted), or local CA via mkcert
• Fallback for off-tailnet use — need a local DNS or /etc/hosts fallback for working without Tailscale
• Reverse proxy choice — Caddy has native Tailscale cert support via caddy-tailscale, making it a natural fit
• Control plane support — client code is merged but the proprietary coordination server also needs to support the dns-subdomain-resolve nodeAttr (issue was closed by a TS employee, suggesting this is ready)

References

• tailscale/tailscale#1196 — Original issue (closed as completed)
• tailscale/tailscale#18258 — Implementation PR (merged Jan 30, 2026)
• tailscale/tailscale#7081 — Wildcard TLS certificates (still open)
• tailscale/tailscale#1543 — Custom DNS records in MagicDNS
• Tailscale Services beta — Related but separate feature

The proposed integration points to devenv.nix and a Caddy or nginx reverse proxy, but no implementation files or tests are identified. Start by reviewing the existing devenv configuration and the linked Tailscale references, then resolve the release, TLS, fallback, and control-plane questions. Done means an agreed, implementable design for worktree hostnames, routing, and off-tailnet behavior.