Run a relay · User guide

Run a relay

"Install Vulos" covers standing up your first relay in a couple of commands. This is the deeper reference for it: the reachability modes in full, running several relays for real redundancy, where Pier fits in, and when to autoscale — for a box you run for yourself or for other people.

~14 minRuns on your instanceNo spec reading required
01

What a relay actually is

A box on home internet sits behind NAT — nothing outside can open a connection to it. So the box opens a connection outward to a machine that does have a public IP, and keeps it open. That machine is the relay. When your phone wants your box, it reaches the relay and the relay passes it through.

  • You run the relay. It is vulos relay serve on a public-IP box you control — a small cloud VPS is ideal.
  • The relay is content-blind. It forwards the encrypted tunnel between you and your box; it never holds or reads your content.
  • Home box opens no ports. All the inbound-facing exposure lives on the relay VPS, which is the public endpoint you operate.

There is no Vulos-run relay and no “os.vulos.org” that works out of the box. Reachability behind NAT is something you stand up yourself. That is the sovereign trade-off — nobody else is ever in your path.

Not run one yet? Install Vulos has the quick vulos relay serve command that gets your first one up in a couple of minutes. From here on, this is the deeper reference.

your boxbehind NATHOME ROUTER · NO PORTS OPENDIALS OUTrelaya relay you run · cloud VPSyour devices
Your box dials OUT to the relay and holds the line; your devices arrive through it.
02

The reachability modes

“Relay” is one of a few ways a box can be reachable. Match the mode to your situation:

  • Direct — your box already has a public IP (a VPS, or a home line with a static IP and a forwarded port). No relay needed; the box answers on its own address.
  • Relay (default behind NAT) — the box dials out to a relay you run. This is the path for the common home-router case.
  • LAN — on the same network, devices reach the box directly by its local address, relay or not.
  • TURN / media — real-time audio/video can use your own STUN/TURN server for the media path, independent of the control tunnel.

These aren’t exclusive: a box can be direct on its LAN and relayed from the outside at the same time. The OS picks the best available route per connection.

Settings → Network → Relay & Reachability, showing the active ingress mode and relay nodesSettings → Network → Relay & Reachability, showing the active ingress mode and relay nodes
Settings → Network → Relay & Reachability — the ingress mode and your relay nodes, live.
03

Run several for redundancy

One relay is a single point of failure. Add more and the box holds a line to each, falling over instantly if one dies:

  • Run at least three. Rendezvous discovery wants ≥3 disjoint-operator nodes — three relays run by three different people (or at least in three different providers/regions) so no one operator or outage takes you offline.
  • Spread them out. Different providers and regions beat three VMs in one datacentre.
  • Paste all of them into Relay & Reachability. The box maintains a tunnel to each and picks by latency and load; if one drops, traffic is already flowing over the others.

Relays are cheap and stateless — they store nothing and forward ciphertext — so running three costs little and buys real resilience.

your boxon your hardwareOPTIONALos.vulos.orgREACH FROM ANYWHERE · NO PORTS TO OPEN
Three relays, ideally three different operators — no single point your box depends on.
04

Pier — an experimental alternative

Pier is an experimental alternative broker from the Kotva ecosystem. Its rendezvous role is wire-compatible with the built-in Vulos relay, so you can point a box at a Pier endpoint — and you can run Vulos relay and Pier together, safely, listing both in the same panel.

Today the supported default is your own Vulos relay. Treat Pier as something to experiment with alongside your relays, not as a replacement for running them.

Settings — Relay & Reachability, the relay node list showing three nodes: two Vulos relays and a Pier broker, all healthy with live tunnels
Pier sits alongside your Vulos relays; it does not replace them.
05

When to autoscale

A relay’s work is forwarding bytes, so it’s bound by bandwidth and open connections, not CPU. Scale accordingly:

  • Scale out, not up. Add more small relays rather than one large one — it also improves your disjoint-operator count.
  • Watch the right signals — sustained network throughput and concurrent tunnels, not CPU load. Add a node when either nears the instance’s ceiling.
  • Autoscale on connection count where the provider allows it (Fly Machines, a Hetzner/DO instance group behind round-robin DNS). Keep at least one always-running node so nothing cold-starts into your reach path.
  • DNS round-robin across relay IPs spreads new boxes evenly and lets you retire a node by pulling its record.

For most people three modest relays never need autoscaling at all — reach for it only when you’re fronting many boxes or heavy media.

.img.gzUSB / Etcherboot · signed
Scale relays horizontally: add nodes, not bigger nodes.

What you have now

  • A relay of your own running Vulos in relay mode on a public IP
  • Your home box reachable through it, with zero ports opened at home
  • Several relays across different operators for real redundancy
  • A clear rule of thumb for when to add capacity