Use Headscale and Tailscale at the same time on one machine

Yes — you can be connected to a self-hosted Headscale network and a regular Tailscale tailnet at the same time, on one machine, with the official client having no idea it's happening. The official Tailscale client can only talk to one coordination server at a time, so Headscale-vs-Tailscale is normally an either/or. TailMux removes the either/or: each network is a profile with its own embedded node and its own control_url, all live simultaneously, with traffic routed to the right network by hostname.

This is the classic self-hoster split — a Headscale-coordinated homelab plus a managed Tailscale tailnet for work (or for the one network where you want Tailscale's hosted conveniences) — and it's an open feature request against the official client (#16430).

Why the official client makes this an either/or#

A Tailscale client binds to exactly one control plane. Point it at your Headscale (tailscale up --login-server=https://hs.example.com) and it is a Headscale client; point it back at Tailscale's coordination server and your Headscale net goes dark. Fast user switching doesn't help — it switches between stored logins, one active at a time, regardless of which control plane each uses.

The pre-TailMux answers are the usual suspects: a second tailscaled dedicated to Headscale (with the route/DNS/firewall contention that entails) or a container per control plane. Their commands and failure modes are covered in the Linux guide; the underlying reason they're fragile is in the architecture explainer.

One profile per control plane#

In TailMux, the coordination server is just a per-profile setting. Each profile is an independent embedded node, so pointing one at Headscale and another at Tailscale is no different from running two Tailscale accounts:

1profiles:2  homelab:3    control_url: https://hs.example.com     # your Headscale server4    suffixes:5      - .home.example                       # your Headscale base domain6  work:7    # no control_url -> Tailscale's coordination server8    accept_routes: true9    suffixes:10      - .work.ts.net

Run tailmux config validate, then tailmux up. Nothing about the two control planes interacts: different servers, different node keys, different DNS — and, as everywhere in TailMux, a name owned by one profile is never dialed through the other.

Suffix planning for a Headscale network#

The router dispatches by hostname suffix, so each network needs a suffix that's actually yours:

• Headscale with a custom base domain (the common case): Headscale serves MagicDNS under the base_domain you configured — say home.example. Give the profile that suffix, and nas.home.example routes to the homelab.
• The managed tailnet keeps its assigned *.ts.net name, e.g. .work.ts.net.
• Don't claim bare .ts.net. Suffixes are owned exclusively, and an unowned .ts.net name is refused rather than guessed — claim only the tailnet domains that are really yours.

If a homelab host is reachable by IP subnet rather than by name (behind a subnet router you advertised through Headscale), set accept_routes: true on that profile.

Logging in: Headscale vs Tailscale#

Each profile logs in against its control plane:

$tailmux profile login work      # normal Tailscale browser auth$tailmux profile login homelab   # your Headscale flow (OIDC or headscale CLI approval)

For the Headscale profile you'll complete whatever flow your server is configured for — OIDC, or approving the node with headscale nodes register on the server. Once registered, the node appears in headscale nodes list like any other machine; the work profile appears in the Tailscale admin console. Neither list knows about the other.

Verify both are live#

$tailmux status                                    # both profiles up, each with its control plane$tailmux test nas.home.example                     # -> homelab$tailmux test host.work.ts.net                     # -> work$tailmux dns query --profile homelab nas.home.example

From there, everything in TailMux works identically across both: tailmux ssh admin@nas.home.example opens a shell on the Headscale net while a Service Tunnel keeps a work database on a fixed local port — at the same time, in the same shell.

Isolation between a homelab and a work tailnet#

Mixing a personal control plane with an employer's tailnet is exactly where isolation matters most, and the guarantees are structural: profiles never bridge, a suffix belongs to exactly one profile (overlaps are rejected at validation), and there is no fallback dial. Your Headscale net can't see or transit the work tailnet; work traffic never touches your server. Your machine is simply a member of both, with a hard wall between.

The bottom line#

Headscale-or-Tailscale is a limitation of the official client's one-control-plane design, not of the protocol. Give each control plane its own profile — one control_url line — and both networks are live at once, routed by hostname, isolated by construction. Setup details live in the macOS and Linux guides; config reference in the docs.