A second Tailscale tailnet on macOS: OrbStack/Lima VM vs no VM at all

No — you don't need a VM to use a second Tailscale tailnet on macOS. The OrbStack/Lima recipe works, but it spends a whole Linux guest to answer one question — which tailnet does this connection belong to? — that can be answered by a hostname router in a menu-bar app. This page compares the two honestly and, if you're already running the VM, shows how to retire it piece by piece.

Why the VM recipe exists#

The Tailscale macOS app is one network extension bound to one account, and the Linux tricks (second daemon, namespaces) don't transplant to macOS. So the community answer became: don't fight macOS — run Linux inside it. Install tailscaled in an OrbStack/Lima/Colima guest, sign the guest into tailnet #2, and reach that tailnet through the VM. It recurs often enough to have a standing HN thread and dedicated GitHub repos. It's a rational workaround for a real gap (#183) — it's just heavy.

What the VM costs on day 2#

Setup is the cheap part. The recurring bill:

• A guest OS that must stay up. The second tailnet is reachable only while the VM runs — a whole Linux system idling to hold one daemon, on battery too.
• Split-brain shells. Work on tailnet #2 happens “inside” the VM: a second SSH config, a second toolchain, and a permanent mental note of which terminal is host and which is guest.
• DNS and port plumbing. MagicDNS for tailnet #2 exists only inside the guest. Reaching it from a native macOS app — a database GUI, an RDP client — means hand-maintained port-forwards out of the VM.
• Three update surfaces. The guest OS, the VM runtime, and macOS each update on their own schedule, and each can break the bridge.

Side by side#

Retire the VM: a migration checklist#

Already running the OrbStack setup? Map each thing the VM does to its native replacement, then delete the guest.

1. Inventory what the VM actually provides. Usually three things: reachability of tailnet #2's names, a handful of port-forwards to specific services, and a shell that's “on” that tailnet.
2. Create a profile for tailnet #2 in TailMux owning its suffixes (e.g. .work.ts.net), tailmux profile login work, and verify with tailmux test host.work.ts.net. Full steps in the macOS guide.
3. Replace each port-forward with a Service Tunnel. For every ssh -L/VM forward you kept alive, create a tunnel under Open → Tunnels: profile work, target db.internal.example:5432, and TailMux assigns a stable 127.0.0.1 port your GUI keeps forever. Targets reachable only via a jump host use the SSH-bastion mode (bastion.example.ts.net, auth via ssh-agent, key, or Keychain-stored password) — the one case where the VM's ssh gymnastics survive, now managed with a menu-bar switch. (Tunnels docs.)
4. Replace the VM shell with tailmux ssh. Instead of orb → ssh from inside the guest, run tailmux ssh admin@host.work.ts.net from any macOS terminal — it wraps system ssh with the right ProxyCommand and routes through the owning profile.
5. Point the browser at nothing. The app sets the system PAC on launch, so wiki.work.ts.net just loads in Safari. Then shut the VM down, confirm everything still works, and reclaim the RAM.

When the VM is still the right call#

Keep a real tailscaled (in a VM or not) when you need machine-owning features: this device acting as an exit node, advertising subnet routes, or a true system-wide VPN where every protocol from every app is transparently on the tailnet. TailMux deliberately doesn't claim the machine — that's exactly why it can run five tailnets side by side. If your need is “both tailnets reachable at once, by name,” the VM is overhead; if your need is “this Mac is infrastructure for tailnet #2,” the VM (or a dedicated box) remains correct.

The bottom line#

The VM answers a routing question with an operating system. If routing is all you needed, TailMux answers it natively: profiles instead of guests, Service Tunnels instead of port-forwards, tailmux ssh instead of a shell inside a shell. Do the five-step migration in an afternoon — macOS setup guide, pricing, download.