Documentation
Private vigie: prerequisites and sizing
A private vigie is your mesh's public rendezvous point: it helps nodes discover each other and relays traffic when a direct link is not possible. Sizing it well means giving it enough CPU, memory and above all network throughput for the expected number of connections. This page recalls the exposure prerequisites, gives a reference template — a design goal, not a guarantee — lays out the capacity and scale-out logic, and recalls an important principle: the vigie is disposable, its state rebuilds quickly.
Prerequisites
A vigie needs a public IP address and a few ports reachable from the internet. These entry points are what let nodes contact it to discover each other and, when needed, have their traffic relayed. The rest of the mesh's network configuration remains outbound-only on ordinary nodes.
| Port | Role |
|---|---|
| udp/443 | QUIC data plane — main path for relayed flows |
| udp/4433 | QUIC control plane / signalling |
| tcp/443 | Fallback and compatibility when UDP is blocked |
The vigie's role, its place in the architecture and its initial setup are described in the "Deploy your private vigie" page (/en/docs/vigie-privee).
Reference template
To give a concrete starting point, VIGIL-MESH publishes a reference template. It is a design goal: the target the architecture aims for, not a contractual throughput nor a measurement guaranteed on your infrastructure. Real figures depend on your hosting provider, the traffic profile and the share of flows actually relayed.
Two lessons emerge from this template. First, a vigie's critical resource is the network — throughput and packets per second — well before CPU or memory: it is the 5 Gbps throughput that bounds the order of magnitude of the 10,000 connections. Second, relaying is reasoned per core, through the 1 Gbps and 150,000 pps gate: it is the unit from which you estimate a machine's capacity and its headroom.
Capacity and scaling
Starting from the per-core gate, a vigie's capacity is estimated by reasoning about the resource that saturates first. Since the limiting factor is the network, it is the aggregate throughput and the packets per second that need tracking, more than the average CPU load.
- Estimate load from the traffic actually relayed, not from the raw number of nodes: two nodes that reach each other directly consume almost no vigie bandwidth.
- Monitor aggregate throughput and packets per second first, since the network saturates before the CPU in the reference template.
- Add vigies rather than inflating a single machine beyond what one core relays cleanly: scaling is horizontal.
- Spread vigies as close as possible to the node populations to shorten paths and limit relayed traffic.
The vigie is disposable
A vigie keeps no precious, irreplaceable state: it holds rendezvous and session state that rebuilds from the nodes that reconnect to it. This is an architectural choice with a strong practical consequence: a vigie can be replaced, redeployed or moved without a complex backup-and-restore procedure.
In practice, this invites treating vigies as interchangeable resources: prefer redeploying a clean one over lengthily repairing a degraded instance, and plan for several vigies so that an isolated failure has no noticeable effect on the mesh.