nfltr relay

The nfltr relay

Every byte that goes through nfltr goes through the relay. A share link to a dev server, an SSH session through nfltr tcp, a hub talking to its agents on other machines: each is a connection the relay accepts, routes and copies. It runs no model and makes no decisions.

Run your own relay (beta)Go SDKCLI reference

What it carries

Machines connect out to the relay, so only the relay needs an open port. TLS passthrough tunnels, peer-to-peer transfers and WireGuard tunnels are sealed end to end: the relay carries only ciphertext (End-to-end encryption).

nfltr.xyz or your own relay

By default your machines meet on nfltr.xyz, where we run the relay: updates, certificates, uptime. In beta, you can instead run it on a VM or machine of your own, so the path between your machines stays on your network. It is the same nfltr binary. You bring the TLS certificate, either one your machines already trust or a self-signed one the relay creates and your machines pin by fingerprint. The relay creates one API key on its first start; each machine then runs one nfltr config set-relay step, and every nfltr command on it uses your relay.

nfltr.xyzYour own relay (beta)
Who runs itWe do.You do: a VM, its firewall, its certificate, upgrades and backups.
DashboardYes, with Google sign-in.No. Everything works from the CLI.
Hubs, nodes, agents, messages and filesYes.Yes.
Share links, SSH and TCP tunnels, private LANYes.Not in the beta.
AvailabilityOur service.One process on one machine: no failover. Nodes reconnect by themselves after a restart.
nfltr relay serve --data-dir /var/lib/nfltr-relay --tls-self-signed --tls-name relay.lan

The tutorial goes from an empty Linux VM to a goal run by agents on your nodes: Run your own relay (beta). Why we built it and what we checked: Run the relay on your own network.

Measured, final run on released code

Next to frp, rathole, chisel and bore

One Docker harness, the same method for each: throughput, scaling, reliability and footprint, with one CPU and 512 MiB for each relay.

1.26×
frp's rate for bulk TCP over 8 streams
2.10×
frp's rate for small HTTP requests on new connections
75 %
of frp's rate for a single request's latency: still trails

The relay also uses more memory per tunnel. The post covers the method, the bugs we found, what changed, the conformance suites we ran, and where nfltr still trails: A faster, leaner relay, measured against frp, rathole, chisel and bore.

From your own programs

The Go SDK embeds a tunnel agent in a Go program: it wraps the gRPC transport the CLI uses, connects out to the relay and serves the program's own HTTP handlers, with no subprocess or sidecar (overview).

More