Do I need Tailscale to use dev-mux? The honest answer

Short version: no, Tailscale is not a hard requirement. It's what we *recommend* because it's the easiest way to get a secure private network between your machines — but the dev-mux Tailscale requirement is a recommendation, not a dependency baked into the code. dev-mux talks to your machines over SSH, and it will use any SSH destination you can reach. Tailscale is one good way to make that destination reachable and private. It is not the only way.

This is the single most common question we get before someone signs up, so it's worth answering precisely rather than waving at it.

What dev-mux actually needs

dev-mux is mission control for your AI coding agents. A small per-tenant coordinator VM — the hub — keeps persistent terminal sessions to your own machines, where your agents run. For that to work, the hub needs exactly one thing:

That's the whole contract. Any network path that lets the hub reach your machine by SSH satisfies it. The code does not check for Tailscale, require a tailnet, or refuse to run without one — it resolves a host and connects.

Why we recommend Tailscale anyway

If the requirement is just "reachable over SSH," why do we point almost everyone at Tailscale? Because for a solo developer or small team it removes the two annoying parts of that sentence — *reachable* and *private* — with almost no work:

workstation behind a home router, a cloud VM, a Raspberry Pi — they get a stable private address and can talk to the hub without you opening ports to the public internet.

tailnet. Nothing is exposed publicly just to let the hub connect.

So the recommendation is a *convenience and security* recommendation, not a lock-in. We'd rather tell you the honest boundary than pretend a tool is mandatory when it isn't.

The connectivity ladder: from localhost to a full tailnet

Because the only real requirement is SSH reachability, dev-mux supports a range of setups — pick the rung that matches your environment:

network fabric at all.

on Tailscale's coordination service, run your own control server. dev-mux treats a self-hosted mesh as a first-class option.

path to a private, roaming, port-forward-free fleet.

The point of the ladder is that *you* choose the trade-off. Air-gapped shop that can't use a hosted coordinator? Self-host the mesh. Just kicking the tires on one machine? Stay local. Ready for the easy, private, everywhere setup? Use Tailscale. None of these change what dev-mux stores or where your code runs.

What doesn't change no matter which rung you pick

The connectivity choice is orthogonal to the thing that actually matters — the trust model is identical on every rung:

hub is a relay, not a host. It coordinates terminal sessions; it does not run your workloads and does not custody your code or secrets at rest.

no transcripts. (Live terminal content *transits* the hub's memory while you're connected — that's how a relay works — and an optional screenshot feature can capture images if you turn it on. That's transit and opt-in capture, not a copy of your codebase at rest. We say "never stored," not "never touches," and we mean exactly that.)

reconnect — close the lid on the train, reopen at your desk, and your work is where you left it. That durability comes from tmux on the hub plus resilient reconnect on every surface, not from your network fabric.

The honest takeaway

Tailscale is the fastest, safest on-ramp we know of, so it's what we recommend and what our defaults assume. But the dev-mux Tailscale requirement is not real: the code needs SSH reachability, and Tailscale is simply the easiest way to provide it. If Tailscale fits your environment, use it and you'll be running in minutes. If it doesn't, you have a ladder of alternatives — LAN, a self-hosted Headscale mesh, or a single local box — and none of them compromise the zero-code-on-our-servers model.

---

*Curious how the sessions survive a dropped connection in the first place? See the companion post on durable AI agent sessions. Wondering how you'd fly many machines at once? See "Managing a fleet of AI coding agents from one pane of glass."*