Frequently asked questions

VIGIL-MESH is a next-generation mesh VPN: an end-to-end encrypted private network that connects your machines, sites and services as if they were on the same local network — device discovery, multicast and real time included. Every device that joins the mesh becomes a node reachable at a stable address, without exposing your infrastructure to the rest of the Internet.

A classic VPN is star-shaped (hub-and-spoke): all traffic climbs up to a central gateway, which becomes a bottleneck and a single point of failure. A mesh VPN establishes direct peer-to-peer links between machines: traffic takes the shortest path, latency drops, and there is no longer a single concentrator to saturate.

Beyond the topology, VIGIL-MESH behaves like a true LAN: IP broadcast and multicast cross the encrypted mesh, so device discovery works from one site to another. A classic enterprise VPN mostly carries application-level point-to-point traffic and drops this broadcast traffic.

VIGIL-MESH is aimed first at organizations that need to connect sites, machines and services — industry, robotics, construction sites, device fleets. But the client is a free download and an individual can perfectly well connect their own machines. The service is subscribed to per workspace.

For an ordinary node, no: there is no inbound port to open, the client always connects outward. Only a vigie (the relay) needs public inbound ports, because its role is precisely to be reachable in order to relay and to coordinate NAT traversal.

No, and we say so clearly: VIGIL is a layer 3 (L3) overlay that reproduces the behavior of an L2 broadcast domain, not an Ethernet bridge. IP broadcast and multicast cross the mesh as on a switch, but arbitrary Ethernet frames are not bridged. A product like ZeroTier does true L2 (bridged Ethernet); VIGIL chooses an L3 overlay with L2-style broadcast.

Yes: mDNS/Bonjour, SSDP/UPnP and WS-Discovery rely on IP multicast and broadcast, which VIGIL replicates in encrypted form across the mesh. A printer, a Chromecast or a camera discovered on one site then shows up as if it were on the local network of the other sites of the same network.

Yes. Each sender broadcasts under a sender key that rotates when a member is revoked, when it reconnects or restarts, and at the latest every 24 hours. The vigie replicates the packets to the receivers without ever being able to read them: broadcast follows the same encryption rule as point-to-point traffic.

Since IP multicast is replicated across the mesh, DDS discovery — which ROS 2 relies on — can span several sites without an application gateway. Formal validation of ROS 2 is however on the roadmap: on very large graphs, discovery traffic can be intense and we recommend keeping an eye on storm control. To be validated case by case before any critical deployment.

Yes. Games that discover their matches through UDP broadcast on the local network, like industrial protocols that announce themselves over broadcast UDP, cross the mesh because VIGIL carries IP broadcast and multicast. From the application's point of view, everything happens as if the machines shared the same LAN segment. On large graphs, a storm-control mechanism prevents a broadcast storm from saturating the network.

A vigie is the infrastructure's relay: it helps two nodes find each other, coordinates NAT traversal and temporarily relays traffic until the direct link is established. It is structurally blind — it only ever sees packets that are already encrypted end to end.

Yes. It is the same binary and the same protocol as the vigie operated by the infrastructure — no fork. Your private vigie self-configures against the controller with a one-shot fleet token and only ever serves the networks of your own workspace.

No. It is blind by construction: it holds no session keys and sees only opaque flow identifiers, packet sizes and timings. Even fully compromised, a vigie yields nothing but metadata, never the content or the keys.

Yes, unlike a node: a vigie needs three public inbound ports (udp/443, udp/4433, tcp/443), because its role is to be reachable from the Internet to relay and to coordinate NAT traversal. It is the only actor that exposes ports.

The vigie keeps serving the networks already allocated to it and never accepts another client. Without the controller, it can neither change scope nor claim a new workspace: the islands already formed remain autonomous, but no new allocation is possible.

The session connecting two machines IS an end-to-end QUIC connection: encryption comes from TLS 1.3 and peer authentication relies on raw Ed25519 public keys (raw public keys, RFC 7250), with no certificate chain to manage. There is only one encryption layer, not a tunnel inside a tunnel.

Yes, for the end-to-end QUIC sessions: key establishment is hybrid X25519 + ML-KEM768. “Hybrid” means the session key depends on both mechanisms at once and stays safe as long as either of the two holds — a defense against the “harvest now, decrypt later” scenario. This protection covers the QUIC sessions, not yet the whole discovery surface.

No, not to date, and we prefer to say so honestly. The documentation describes the design of the security model; an external audit is part of the roadmap. Until that step has taken place, we do not present VIGIL-MESH as “audited” nor as definitively ready.

Revocation is immediate and combines two actions: removing the member from the signed network map (netmap) distributed by the controller, and immediately rotating the group keys still in use. A revoked member can no longer establish a new session nor decrypt broadcasts issued after its revocation.

Only metadata. The vigie sees opaque flow identifiers, sizes and timings, never the content or the keys. The controller knows the identities, the policy and the member directory, but not the content of your end-to-end flows.

No. Node private keys never leave the machine that generates them. This is what makes the compromise of a vigie harmless to authenticity: an attacker who takes over a relay cannot forge a node identity, lacking the corresponding private keys.

The client always establishes an outbound connection to the vigie, which coordinates NAT traversal (hole punching) between the two peers. The connection is first established through the blind relay — hence immediately — then switches without interruption to the direct peer-to-peer path as soon as it is available.

VIGIL favors QUIC over UDP, but when a network blocks UDP it falls back to a tcp-only profile (tcp/443) to remain reachable where only outbound web traffic is allowed. Throughput may be lower than over UDP, but connectivity is preserved.

Yes. QUIC connection migration makes it possible to change interface or IP address — going from Wi-Fi to 4G, changing sites — without breaking the session or restarting the negotiation. Ongoing sessions continue transparently.

No: each node receives a stable address within the network, independent of its physical address of the moment. You reach a machine at the same address whether it is at the office, on the move or behind another NAT.

No. No inbound port or public IP address is required on the node side: providing reachability is precisely the vigie's role. This is what makes it possible to connect a site behind a carrier-grade NAT (CGNAT) or a network that only allows outbound traffic.

The client exists for Windows, desktop Linux, Android and NVIDIA Jetson backend targets. A WebAssembly (WASM) core additionally lets a browser join the mesh. The list of signed builds is published on the download page.

Yes. The client core is compiled to WebAssembly and connects via WebTransport (QUIC/HTTP3): a browser tab becomes a full node, not a mere web client leaning on a gateway. This is what makes it possible to drive mesh services directly from a page.

Yes: NVIDIA Jetson targets are supported, which covers robotics, vision and edge computing uses. The same protocol connects an embedded Jetson, a Linux server and a Windows workstation in a single network.

The officially listed platforms are Windows, Linux, Android and Jetson, plus the browser via WASM. Refer to the download page for the up-to-date list of available builds: we prefer not to announce a platform until its build is published.

Yes: this is a central use of VIGIL-MESH. You publish a service (web interface, API, stream) reachable by the members of your network without opening a port or exposing your infrastructure to the rest of the Internet. The service stays within the encrypted perimeter of the mesh.

Yes. The application platform can serve sites (HTTP/WSS) accessible to the members of the network. Combined with exposure-free publishing, this enables an intranet or an internal portal reachable without a public gateway.

The application platform integrates mail, no-code databases and a no-code studio for building internal applications. The goal is to cover the common building blocks of a private information system without exposing them publicly.

Yes: MCP (Model Context Protocol) connectors let you plug an AI assistant into the services published in your network. The AI accesses internal resources through the encrypted perimeter of the mesh, without those resources being exposed on the Internet.

Yes. Since the browser can be a node via the WASM core and WebTransport, a web page can directly consume the services published on the mesh — without an intermediate gateway that would break the end-to-end encryption.

The local multi-process measurement bench processed 1,000,000 packets with zero loss, at more than 350,000 packets per second. The context must be stated: this figure is measured in loopback (several processes on a single machine), neither over WAN nor across several hosts. It is a data-path throughput measurement, not an end-to-end performance over the Internet.

No WAN latency measurement is published to date. On the direct path, since the session is peer to peer, latency is essentially that of your own network between the two machines. We do not communicate a numeric RTT, for lack of a representative WAN measurement to present.

Two things must be distinguished: measurements (what the bench actually observed) and SLOs, which are design objectives. A design objective is not a measurement and we never present it as one. End-to-end WAN figures will depend on your network and your real conditions.

The relay is only used at startup, while the direct link is being established; traffic then switches without interruption to the peer-to-peer path, the shortest one. When NAT traversal fails and the relay remains necessary, the path goes through the vigie, which can add latency depending on its location.

No, caution is required: the figures quoted come from a loopback bench and VIGIL-MESH is not presented as definitively production-ready. Measure in your own environment before any critical sizing.

Create an account: a workspace is then provisioned for you. You then download the client onto your machines, they join the mesh and become reachable at a stable address. The console gives you topology, policy and audit in a single place.

Yes, downloading the client is free on all platforms. The service itself is subscribed to per workspace: that is the level at which members, networks and policy are organized.

Two plans. Free, for individuals: unlimited direct peer-to-peer traffic and a monthly quota of vigie-relayed traffic for each device (billed per GB beyond it). Pro, for professionals: a monthly subscription that includes devices and a dedicated vigie, then a fixed price per additional device, with no usage limit. The complete, up-to-date grid is published on the Pricing page of the site.

You can self-host your own vigie (the relay), with the same binary as the infrastructure. The controller (the directory and the policy) remains operated as a service: it is what provisions the workspaces and distributes the signed network maps.