Explore formal Tailscale integration for exe.dev

[josharian]

Author: jimmcslim75
Channel: #feedback
Link: https://discord.com/channels/1405685085923049482/1405686161791516873/1529332069329535126

---

Description

User is requesting consideration of a formal Tailscale integration for exe.dev. While the specific implementation details are open, the user believes this could streamline and improve the user experience.

Original Message

Are there any plans for a formal Tailscale integration? I'm not 100% sure what it would look like, but I feel you have the opportunity to add something to exe.dev to make the process a little more seamless

— jimmcslim75 (2026-07-22)

Context

This request comes in the context of ongoing discussions about network/firewall compatibility and workarounds with exe.dev domains and CNAME solutions.

Next Steps

• Evaluate feasibility of Tailscale integration
• Define what "seamless" integration would look like
• Assess user demand and priority

[jimmcslim]

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).