Access multiple
Tailscale tailnets
simultaneously.
TailMux lets one Mac or Linux machine reach resources in independent tailnets through supported browser, command, SSH, and local TCP-tunnel paths. It selects a profile by hostname suffix, with a hard wall between profiles. It does not add another system-wide VPN interface or change the official Tailscale client session.
Choose your next step
One Mac. Several tailnets. No bleed.
Account switching is useful when one tailnet is needed at a time. It is not the same thing as concurrent app-layer access to resources in independently configured tailnets from one workstation.
TailMux decides where a request goes from its hostname, while that name still means something. A name owned by one profile never falls back to another. That one rule is the whole product.
Routing you can reason about
No daemon soup, no magic. Six behaviors, each one a consequence of the same rule about names.
Suffix routing
Each request is matched on its hostname suffix and handed to the one profile that owns it. The name is the routing key — it's decided before it can collapse into an IP.
Hard isolation
A name owned by one profile never falls back to another. Separate identities, state dirs, sockets and node keys per tailnet. Nothing bridges.
Embedded tsnet
Every profile runs its own Tailscale node inside TailMux — own hostname, own key, own state. No second system VPN route, no kernel route to fight over.
Browser PAC
A generated PAC sends only your owned suffixes through TailMux; everything else stays direct. The app sets it as your system proxy on launch, so Safari just works.
Service tunnels & SSH
Pin a database, RDP or SMB service to a fixed 127.0.0.1 port through one profile — kept alive for you, with an SSH-bastion mode for hosts only a jump box can reach. tailmux ssh drops you into a shell on any host through its owning profile, and tailmux run / env push curl, git and npm through the right one.
Honest diagnostics
tailmux diag path tells you who owns a host, whether the peer is visible, direct or DERP, and where the milliseconds go. diag fetch compares the paths side by side.
The hostname is the routing key
Everything happens at the proxy layer, while the name is still readable — never after it has turned into an ambiguous address.
- 01
The name survives
Your client sends the request with its hostname intact — over HTTP_PROXY, the PAC, or tailmux connect. Nothing has guessed an IP yet.
- 02
The router matches a suffix
On 127.0.0.1:43100, TailMux matches that name against each profile's suffixes. Overlaps are rejected when you save the config, not at runtime.
- 03
It dials the owner — only the owner
The request goes through the embedded node for that one profile. No match means denied. It is never quietly retried somewhere else.
- 04
It lands on the right tailnet
Direct or over DERP, on the tailnet you meant. Your everyday Tailscale app and its account are never touched.
1client keeps hostname2 |3 v4TailMux router 127.0.0.1:431005 |6 | hostname suffix match7 v8profile-owned embedded tsnet9 |10 v11selected tailnet (direct / DERP)It's a CLI first
The menu bar and web GUI are thin wrappers. Anything they do, you can script, pipe or watch from a shell.
$tailmux profile list$tailmux profile login personal$tailmux profile status work$tailmux status
$tailmux test nas.home-lab.ts.net$tailmux connect nas.home-lab.ts.net 8080$tailmux pac serve$tailmux env
$tailmux ssh admin@host.work.ts.net$tailmux tunnel --profile work \--listen 127.0.0.1:13389 10.10.20.15:3389$tailmux run curl https://grafana.work.ts.net/
$tailmux diag path <url> --netcheck$tailmux diag fetch --modes router,direct <url>$tailmux gui serve$tailmux tui --target <url> --watch
Native on macOS, headless on Linux
One statically linked Go binary, signed releases, nothing to install alongside it.
macOS
Menu bar app, full CLI and the Safari PAC path. The menu bar talks to tailmux gui serve over loopback. Intel and Apple Silicon.
Linux
The whole routing core — proxy env, tunnels, tailmux connect and diagnostics — for servers and dev boxes. amd64 and arm64.
Isolation isn't a setting
These aren't toggles you can flip off. They're enforced in the router and the config, and they're the reason TailMux exists.
- Traffic never bridges between profiles.
- An unclassified .ts.net name is never routed.
- A failed connection never falls back to another tailnet.
- Every proxy and control port binds to loopback only.
- State, sockets, logs and runtime dirs stay separate per profile.
- The official Tailscale account and session are never touched.
Questions people actually ask
The short version of what people ask before switching from account-juggling to routing by name.
Can you connect to two Tailscale networks at the same time?
TailMux is built for simultaneous access to resources in multiple independent Tailscale tailnets on macOS and Linux. It keeps a separate profile per tailnet and routes supported hostname-based connections to the profile that owns the suffix.
Can you be logged into two Tailscale accounts on one machine?
Account storage and account switching are different from simultaneous access. TailMux uses a separate embedded profile per configured tailnet, so supported connections can use more than one configured profile without changing the official Tailscale client session.
What is the difference between fast user switching and simultaneous tailnets?
Fast user switching changes which account or tailnet is active. TailMux keeps its configured profiles available to supported paths and selects a profile per hostname-based connection, so a workflow does not need an account switch for every destination.
How do I use a work and personal tailnet on the same Mac?
Define a TailMux profile per tailnet and assign each profile non-overlapping hostname suffixes. Supported traffic for each suffix goes to its owning profile; a name owned by one profile never falls back to another.
Does Tailscale support multiple tailnets simultaneously?
Tailscale offers account and tailnet-management features for its own client. TailMux is an independent macOS and Linux tool for a different local workflow: routing supported hostname-based connections across separately configured profiles without changing the official client session.
Do I need a VM (OrbStack or Lima) to use two tailnets on macOS?
No, not when the workload fits TailMux's documented browser, command, SSH, or local TCP-tunnel paths. A VM remains appropriate when you need a separate full operating environment or native system-level networking.
One-time purchase · 1 year of updates · yours forever
Stop switching accounts. Start routing by name.
Install it, then reach configured resources through the documented access path without crossing profile boundaries.