Documentation
Reach your homelab from anywhere — no exposed reverse proxy
Every self-hosted homelab runs into the same question: how do you access it from outside without exposing it to the internet? The classic answer — public reverse proxy, certificates, fail2ban, dynamic DNS — works, but it turns remote access into a second homelab to maintain. VIGIL-MESH approaches the problem the other way around: nothing is exposed, yet everything is reachable. Your machines connect to each other over outbound, end-to-end encrypted sessions, every service is reached by its machine’s name, and the little that genuinely should be public — a blog, a gallery — goes through an explicit publication, kept separate from everything else.
The classic exposed-homelab stack, and what it costs
To make a homelab reachable from outside, the traditional recipe stacks several layers: a port forward on the router towards a reverse proxy (Nginx, Caddy, Traefik…), a TLS certificate per service name, an authentication layer in front of the admin interfaces, fail2ban or an equivalent to absorb login attempts, and dynamic DNS to track the public IP address whenever it changes. Each layer is reasonable on its own; it is the whole that weighs you down.
- A permanent attack surface — an open port is scanned around the clock. Every service behind the reverse proxy is one misconfiguration or one vulnerability away from being reachable by anyone.
- Recurring maintenance — certificate renewals, security updates for the proxy and the authentication layer, fail2ban rules to tune, configuration to redo every time a service is added.
- A dependency on the public address — dynamic DNS chases the changing IP, and the whole edifice assumes a public address exists at all. Behind CGNAT (many recent fibre plans, 4G/5G), there is simply no port to open: the classic stack cannot be hosted there.
- An implicit all-or-nothing — the same public entry point serves the hypervisor’s interface, the password manager and the blog. Yet those three do not have remotely the same audience.
The opposite model: nothing exposed, everything reachable
VIGIL-MESH reverses the reasoning. Instead of opening a hole in the firewall to let traffic in, every machine — the homelab server as well as the laptop on the road — only makes outbound connections: a single flow on 443 UDP, the same port as the modern web. No inbound port, no router port forward, no firewall rule to create. The connection is established immediately through a relay, then migrates without interruption to the direct path as soon as NAT traversal succeeds — including behind CGNAT, precisely where the classic stack cannot exist.
Sessions are QUIC/TLS 1.3 connections encrypted end to end between the machines, with a hybrid post-quantum key establishment (X25519 + ML-KEM). Each machine gets a stable address (within 100.64.0.0/10) and a MagicDNS name: you reach “nas” or “proxmox” by name, from anywhere, exactly as on the local network. Name resolution is purely local, served from a signed network map: no DNS query for mesh names ever leaves the machine.
| Exposed stack (public reverse proxy) | Private mesh (VIGIL-MESH) | |
|---|---|---|
| Inbound port on the router | Required (port forward) | None — outbound 443 UDP only |
| Who can attempt to get in | The entire internet | Only network members, as allowed by ACLs |
| Certificates to manage | One per public name, renewed forever | None for private access |
| fail2ban / IP filtering | Necessary | Moot: nothing listens publicly |
| Dynamic DNS | Necessary if the IP changes | Moot: stable addresses on the mesh |
| Behind CGNAT | Impossible | Works (outbound only) |
Another difference that matters for a homelab: each VIGIL-MESH network is a broadcast domain. IP multicast and broadcast travel through it, encrypted end to end, so device discovery — mDNS/Bonjour, SSDP/UPnP, WS-Discovery — works across the mesh as if on one local segment. Applications that find your NAS or your media devices by announcement keep finding them when you are away, where most purely L3 VPNs drop that discovery.
What a homelab looks like on the mesh
Concretely, nothing changes inside the homelab itself: services keep running as before, on the same machines and the same ports. What changes is how you reach them. The client installs on the machines (Windows, Linux, Android, Jetson) or on the host or VM that carries them, and each service becomes reachable by its machine's name followed by the service's usual port.
- The hypervisor — the Proxmox VE web interface (port 8006 by default) opens via the host machine’s name, without ever being exposed to the internet.
- The NAS — admin interface, file shares and backups are reached by the NAS’s name, just like from the living room.
- Monitoring — a Grafana dashboard, a Portainer or any other admin tool can be consulted remotely by name, with no added public authentication layer in front.
- The forge and the passwords — a Gitea instance or a Vaultwarden stay strictly private: reachable by network members, invisible from the internet.
- Home automation — Home Assistant (port 8123 by default) can be driven from outside without any public exposure of its interface.
These examples are deliberately generic: VIGIL-MESH has no per-application integrations, and needs none. Anything that speaks IP — web interface, SSH, file sharing, video streams — crosses the mesh as is. If the service works locally, it works remotely, under the same name.
Separating private from public
A homelab actually hosts two families of services that the classic stack lumps together: those with a single legitimate user — you — and those meant to be read by everyone, like a blog or a public gallery. The sound model treats them differently: the mesh for the private, an explicit publication for the public.
The mesh for you
Hypervisor, NAS, monitoring, forge, password manager: all of it stays on the mesh, reachable by name, encrypted end to end, invisible from the internet. No public certificate, no exposure hardening to keep up.
Publication for the public
For the little that genuinely must be public, an HTTP publication opens one precise door towards one service: the platform receives the public traffic, obtains and renews the TLS certificate automatically, and relays the request to the service across the mesh. The machine hosting the blog still opens no port at all.
A publication targets a single service: the visitor sees a URL, and nothing else. They learn nothing about the homelab's topology, the machines' names, or the services that stayed private. Publishing the blog does not open access to the NAS next door. For a non-web service, a TCP publication exists too — keeping in mind that the stream is then relayed as is, and the protocol must provide its own encryption.
Sovereignty: what runs on your hardware, and what does not
A self-hoster wants to know precisely where their bytes travel and whom they depend on. Let us be blunt. The data path is encrypted end to end: relayed or direct, the content of your sessions is readable only by your machines. When a relay is involved — while the direct path is being established, or permanently when both NATs prevent it — that relay (the “vigie”) is structurally blind: it does not hold the keys and never sees the content.
And you can host the vigie yourself. A private vigie installs on your own server — it needs a public IP and three inbound ports (udp/443, udp/4433, tcp/443) —, registers with the controller using a one-shot token, and serves your workspace exclusively: your relayed bytes then only transit through a machine of yours. The full guide is at /en/docs/vigie-privee; the standalone vigie is in preview, and the complete enrollment loop is under qualification.
Inviting family or a friend, without handing over the lab keys
Sooner or later, someone else needs access to a service: the media server for the family, a file share for a friend. With the exposed stack, this often ends as a shared account on a public interface. On the mesh, an invitation is an enrollment like any other — framed by access control lists (ACLs).
VIGIL-MESH ACLs deny by default: belonging to the network grants no right by itself, and only what is explicitly allowed goes through. Rules are written by identity — machines, groups, tags —, never by IP address: a rule saying “the guests group may reach the media server's machine, and nothing else” stays true whatever device the guest uses or network they connect from. Every policy change produces a generation signed by the controller, which each client verifies before applying it.
- Enroll the guest’s device with a one-time key, and place it in a dedicated group (for instance “guests”).
- Write a minimal rule: the guests group towards the one machine concerned, possibly restricted to the one useful service. Everything else — hypervisor, NAS, passwords — remains denied by default.
- Revoke when it is over: revocation is immediate, and the device instantly loses access to direct flows and broadcasts alike.
Setting up remote access
The setup requires no reverse proxy, no certificate, no firewall rule. It is free for personal use: direct traffic is unlimited, and a quota applies to relayed traffic only.
- 1Create an account and a workspaceThe workspace gathers your machines and networks; everything is administered from its console.
- 2Install the client on the machines involvedThe homelab server (or the host carrying its services) and the devices you want to access it from: workstation, laptop, Android phone.
- 3Enroll each machineNetworks page → Machines → “Add a machine”, with a one-time key per device.
- 4VerifyEach machine receives its stable address and its MagicDNS name; a ping by name from the laptop confirms the path is in place.
- 5Access your servicesOpen the service's interface via its machine's name and its usual port, just like locally — from home, on the road, or behind 4G.
From there, the exposed stack can be dismantled piece by piece: the port forward closes, dynamic DNS and fail2ban lose their purpose for private access, and the reverse proxy — if it stays — only serves what is genuinely public.