Documentation

Your vigie, on your server, for your traffic only

VIGIL-MESH operates the relay infrastructure for you. But you can also deploy your own vigie on your own server: it registers automatically with vigil.design, receives its entire configuration from the controller, and will only ever serve the networks of your workspace. Same binary, same protocol, no fork — and even compromised, a vigie cannot read your traffic.

What a vigie is

A vigie is a blind relay and a NAT-traversal coordinator. That's all: its mission is closed and exhaustive.

Encrypted-packet carrier — it transports bytes it cannot read.
Multicast fan-out — it copies an encrypted stream to the members of a group.
Public-address mirror — it tells each node the address under which it is seen from the outside.
NAT introducer — it puts two nodes in touch so they can open a direct path.
Admission sentinel — it checks that a node is allowed to join before relaying anything.

Nothing else. A vigie never holds a session key, never a cleartext netmap, never a single byte of content. It is disposable: all of its state is rebuilt with the controller in under 60 seconds.

When to deploy your own

The public vigie infrastructure is operated for you. Deploying your own answers specific needs — but never content confidentiality, which is already guaranteed by design.

Sovereignty of the relayed path

Your relayed bytes only ever transit through your own machines, never through a third-party infrastructure.

Proximity

A vigie placed in your datacenter or your region, as close as possible to your nodes.

Compliance

A relay that stays within your contractual and legal perimeter.

Dedicated capacity

A reference template, as a design goal: 4 vCPU / 8 GiB / 5 Gbps for roughly 10,000 connections.

Dedicated to you, structurally

A vigie's "private" scope is bound to exactly one workspace. This scope is set by the controller at the very first registration; it is never configurable locally.

The vigie refuses any allocation coming from another client, even if the controller goes down.
It is never published in the global vigie directory.
It only appears in the netmaps of your own networks.

How it configures itself — step by step

1
PrerequisitesA Linux server with a public IP and three inbound ports open: udp/443 for the QUIC transport, udp/4433 for NAT traversal and tcp/443 for qualification. No other dependency.
2
Generate a tokenIn the console, create a one-shot fleet token. Its scope is private and bound to your workspace, server-side: you don't choose it locally, the controller sets it.
3
Write /etc/vigil/vigie.tomlWrite a minimal configuration file: the token, the controller's pin, the public IP and the advertised capabilities. Everything else — keys, certificate, allocations — comes down from the controller.
4
First startThe register command consumes the one-shot token. In return, the vigie receives its verification keys, its fleet certificate, the list of its siblings and its first allocations.
5
Qualification from the outsideThe controller tests your three listeners from the outside before any traffic allocation. A mere outbound connection never makes a vigie operational: it must be reachable from outside.
6
VerifyQuery GET /healthz, confirm the vigie shows up in the console, then watch your networks switch over to it.

What your vigie will never be able to do

Some guarantees are not settings: they are structural.

Read your traffic — impossible, it holds no session key.
Serve another client — refused, its scope is locked by the controller.
Declare itself private — the scope never comes from the vigie, always from the controller.

Changing scope or owner requires decommissioning it and generating a new token — there is no in-place reconfiguration.

And if you deploy nothing?

You are not required to install anything. The shared public vigies are enough in the vast majority of cases.

Automatic allocation to the nearest vigie: one primary and two backup vigies.
A move only when the gain is significant (at least 30%), to avoid pointless switch-overs.
Nothing to install, nothing to administer.

Availability

Frequently asked questions

Can my private vigie read my traffic?

No. It is structurally blind: it holds no session key and only sees packets that are already end-to-end encrypted. Even compromised, a vigie cannot read your traffic.

Do I have to open ports?

For an ordinary node, no inbound port is needed. For a vigie, yes: it needs three public inbound ports (udp/443, udp/4433, tcp/443), because its role is to be reachable in order to relay and coordinate NAT traversal.

What happens if vigil.design is unreachable?

The vigie keeps serving the networks already allocated to it and never accepts another client. Without the controller, it can neither change scope nor assign itself a new workspace.