Explore formal Tailscale integration for exe.dev

Here's what Shelley worked up for me...

Here's a ready-to-send feature request. I've written it to be self-contained and to speak exe.dev's own model (edge secret injection, integration types, reflection).

Title: First-class tailscale integration type (edge-managed tailnet join)

Summary: Add a native integration type that lets a VM join a Tailscale tailnet without any long-lived secret ever touching the VM's disk — the same "secret lives in the network edge" guarantee that http-proxy, github, and the WIF integrations already provide.

Motivation / problem: The existing http-proxy integration already covers Tailscale's REST API surface perfectly: point --target https://api.tailscale.com/ --bearer tskey-api-… and the VM manages the tailnet with an unextractable token.

What it cannot cover is the surface most people actually want: joining the tailnet. tailscale up --authkey=tskey-auth-… requires the auth key to be physically present on the device at registration, because tailscaled speaks Tailscale's encrypted control protocol to controlplane.tailscale.com — there's no outbound HTTP request for exe.dev to inject a header into. So today the only options are:

1. Store a long-lived auth key on the VM (defeats the whole point of integrations, especially on agent-controlled boxes), or
2. Hand-roll an ephemeral-key mint via the API proxy and pipe it into tailscale up (works, but it's bespoke glue every user reinvents).

This is a real gap for the "put my disposable/agent VM on my private mesh" use case, which is squarely in exe.dev's wheelhouse.

Proposed shape: A new type where the platform holds a Tailscale OAuth client (preferred over static keys) and exposes a small edge endpoint that vends short-lived, tag-scoped, single-use, pre-authorized ephemeral keys on demand:

exe.dev ▶ integrations add tailscale \
    --name tailnet \
    --oauth-client-id … --oauth-secret … \
    --tags tag:exe-vm \
    --attach tag:mesh

On an attached VM, tailscale up "just works" — a helper (or oneshot systemd unit) fetches a 5-minute ephemeral key from tailnet.int.exe.xyz, feeds it to the daemon, and it's never written to disk. The integration would also surface under reflection.int.exe.xyz/integrations so agents like Shelley can discover it.

Why it fits the platform:

• Reuses the existing edge-injection trust model; the OAuth secret stays in infra.
• Ephemeral + tagged + single-use keys keep blast radius tiny and auto-remove nodes when VMs die — ideal for sandbox/disposable VMs.
• Complements, rather than replaces, the http-proxy-to-api.tailscale.com pattern (management vs. join are two distinct surfaces).

Concrete data point for first-class Tailscale support, in case it helps scope this.

Setup: two Macs at home behind one residential NAT, plus 7 exe.dev VMs (all LAX region) on the same tailnet.

Symptom: none of the home↔exe.dev links hold a direct path. From home, all 7 VMs show Relay: "lax" / CurAddr: "" in tailscale status --json (DERP-relayed). The only direct peer is my other Mac on the same LAN.

It's not that hole-punching fails — it succeeds. Under active traffic the path upgrades to direct in ~20 ms (the VM reports active; direct <home-ip>:<port>). It just doesn't hold: the VM's NAT mapping expires after ~1–2 min idle — the public UDP port visibly remaps in tailscaled STUN logs (:38896 → :20059 → :19091 → :51928) — the direct path drops to DERP, and cold-recovery on the next use occasionally takes minutes (home side logs open-conn-track: timeout opening TCP … online=yes, lastRecv=5s → 5m33s before it re-establishes). That gap intermittently breaks a health probe against a VM service.

netcheck on the VM shows MappingVariesByDestIP: false (endpoint-independent), so this isn't the classic symmetric-cloud-NAT worst case — it looks like a short UDP conntrack/mapping timeout on the host masquerade. Per Tailscale's cloud-NAT guidance, the clean fix is taking the NAT out of the loop: a public IP (or stable inbound mapping) with inbound UDP 41641 reachable → stable direct, no DERP.

Today I work around it with a ~15 s keepalive from home, which does hold the paths direct. But a formal integration giving each VM stable inbound UDP 41641 (or a public-IP option) would make that unnecessary and fix it for anyone hitting the same idle-teardown behavior.

Happy to share full tailscale status / netcheck / tailscaled logs if useful.

cc @maisem

Is there any update on this? Now the WIF integration is in please, that solves part of the puzzle but not all of it for straightforward automatic joining of VMs to a tailnet.

No update, I'm afraid. It's still on our radar.

Symptom: none of the home↔exe.dev links hold a direct path.

FWIW, this is the bigger problem for me that I hope would be solved first. I can automate installing the Tailscale client and connecting to my tailnet. But I want a direct connection between VMs inside exe.dev's datacenter for better connectivity/speed/throughput etc. That's essentially my VPC and it if has to go out and then back in, not only is that annoying for me, it's ingress and egress for exe.dev that isn't otherwise needed.

direct connection between VMs inside exe.dev's datacenter

Definitely agreed.

cc @maisem