Documentation

Migrating from Tailscale: a step-by-step guide

You have decided — or almost — to replace Tailscale with VIGIL-MESH? This page is the practical guide: take stock of what you actually use in Tailscale, install VIGIL-MESH alongside it without breaking anything, then migrate machine by machine and service by service, all the way to uninstalling. If you are still weighing the pros and cons, start with the Tailscale alternative page, which helps you decide; here, we do.

Before migrating: take stock of what you use

A successful migration starts with an honest inventory. List what your tailnet actually does for you — not what it could do — and note the VIGIL-MESH counterpart for each use. Most building blocks have a direct equivalent; a few do not, and it is better to know before uninstalling anything.

Your machines

List every device in the tailnet: workstations, servers, phones. On the VIGIL-MESH side, each one will enroll into your workspace through the console’s “Add a machine” wizard, with a single-use key — clients for Windows, Linux, Android, Jetson and even the browser.

Your ACLs

Export or copy your current access policy: who is allowed to reach what. On the VIGIL-MESH side you will recreate it as ordered, identity-based ACLs (machines, groups, tags), with deny by default and signed generations verifiable offline.

MagicDNS

Note the machine names your scripts and bookmarks depend on. VIGIL-MESH also offers MagicDNS: a short, stable name per machine, resolved locally from the signed network map — no DNS query ever leaves the node.

Routes to a remote LAN

If you use subnet routers to reach a remote local network, know that routes to a remote LAN are among the fundamentals both products cover: this use case has its counterpart on the VIGIL-MESH side.

Published services (Funnel / Serve)

If you publish services from the mesh with Funnel or Serve, the VIGIL-MESH counterpart is the built-in mesh proxy. List the services involved so you can switch them over one by one during the coexistence phase.

Discovery and multicast

The uses that did not work, or worked poorly — mDNS, SSDP, application multicast, not natively supported by a unicast WireGuard mesh — are precisely VIGIL-MESH’s home turf: it replicates them encrypted across its overlay. Write them down: they will be your first tests.

Coexistence: install alongside, break nothing

You do not have to shut down Tailscale to try VIGIL-MESH. They are two independent overlays: each has its own network interface and its own addresses, and neither touches the other’s configuration. You can therefore install VIGIL-MESH on your existing machines, evaluate calmly, and keep your tailnet as a safety net throughout the migration.

No configuration conflict. Each overlay manages its own interface; installing one does not reconfigure the other.
No inbound port to open. A VIGIL-MESH node always establishes its connections outward: nothing to forward on the firewall to coexist.
A reversible switch-over. As long as both networks are running, any service can roll back simply by changing the address or name it uses.

The migration, step by step

The sequence below follows the getting-started pages of the documentation; each step links to the corresponding detailed guide. The guiding thread: build the VIGIL-MESH network in parallel, verify, and only remove Tailscale last.

1
Create the account and the workspaceCreate an account: on first sign-in, VIGIL-MESH automatically creates a workspace you own. Enable strong authentication and invite a second administrator. Allow a few minutes, with no hardware or network port involved. Guide: /docs/demarrer-compte.
2
Enroll the machines, one by oneIn the console, on the Networks page, the Machines panel carries the “Add a machine” button: the wizard hands you a single-use enrollment key (it expires after one hour), to pass to the client as a command or as a QR code on mobile. Confirm each machine with “Verify (E2EE)”. Tailscale keeps running alongside. Guide: /docs/demarrer-enrolement.
3
Recreate the access policies (ACLs)Transcribe your policy into the VIGIL-MESH model: ordered rules, evaluated top to bottom (the first match decides), naming entities by identity — machines, groups, tags — with deny by default. It is a good opportunity to tidy up: only open what is still needed. Guide: /docs/config-acl.
4
Set up MagicDNS namesEach machine gets its name at enrollment; you can change it later from the console’s device inventory. Adopt a clear naming convention and point scripts and bookmarks at the new names — resolution is purely local, served from the signed network map. Guide: /docs/config-magicdns.
5
Verify connectivityFour checks, in order: the assigned address (a stable 100.64.x on the VIGIL-MESH interface), the reachability of a peer (ping, then a real service), MagicDNS resolution, and the real-time topology in the console. Each check isolates one layer: if something fails, you know where to look. Guide: /docs/demarrer-verifier.
6
Uninstall Tailscale, machine by machineOnce a machine has all its uses going through VIGIL-MESH — verified, not assumed — remove it from the tailnet, then uninstall the Tailscale client. Proceed machine by machine, keeping the old network as a safety net until the last one; nothing forces you into a Monday-morning cut-over.

After the migration: what changes day to day

Once the switch is done, most things look like before: machines reached by name, peer to peer, with no inbound port. Three things change concretely.

Discovery and multicast work. IP broadcast, multicast and link-local traffic are replicated encrypted across the overlay: mDNS, SSDP, ROS 2’s DDS discovery or LAN gaming get their footing back, where a unicast WireGuard mesh does not support them natively.
The browser becomes a node. A tab can join the mesh thanks to the core compiled to WASM, with an SSH terminal and an RDP desktop to your machines — no bastion, no client to install on the machine you happen to be at.
The transport is QUIC on 443/UDP. The same profile as HTTP/3, an asset on locked-down networks; and when a direct path becomes available, the session migrates from relay to direct without interruption.

Frequently asked questions

Can I run Tailscale and VIGIL-MESH at the same time?

Yes, and it is in fact the recommended way to migrate. They are two independent overlays, each with its own network interface and its own addresses: they coexist without conflict for the duration of the migration, and you only remove Tailscale from a machine once all its uses go through VIGIL-MESH.

Do I have to change my IP addresses?

Your local addresses (10.x, 192.168.x) do not change. On the mesh, each machine receives at enrollment a new stable address in the 100.64.0.0/10 range — stable meaning it does not change on every restart. These are therefore new addresses compared with your tailnet: the simplest approach is to point scripts and bookmarks at MagicDNS names rather than addresses, since the name outlives changes.

How long does a migration take?

It depends mostly on the number of machines and the complexity of your access policy, not on any technical constraint. Creating the account and workspace takes a few minutes; enrolling a machine is quick; recreating the ACLs is usually the largest item. Since both networks coexist, there is no rush: migrate service by service, at your own pace, with no cut-over window to schedule.

Can I reuse my Tailscale ACLs as they are?

No, there is no automatic import. You transcribe your policy into the VIGIL-MESH model: ordered rules evaluated top to bottom, naming machines, groups and tags by identity, with deny by default. Every change produces a signed generation that clients verify, including offline. Use the transcription as an opportunity to drop rules that have become useless.

What happens to my exit nodes?

The VIGIL-MESH documentation does not describe a direct equivalent of exit nodes today (routing all of a machine's Internet traffic through a mesh node). Routes to a remote LAN, on the other hand, are covered. If exit nodes are essential to you, validate that point during the coexistence phase before decommissioning your tailnet — or keep both networks for that use.