Connections between the machines you work on, and agents that run on them.
NFLTR is built on one relay. Tunnels and sharing put a local service, a shell or a file in front of the people and machines that need it. Orchestration runs Claude Code agents on the machines that hold your code, data and access, coordinated by one hub. The relay carries the traffic for both, and the status page shows how the hosted relay serves an hourly canary.
Every machine connects out to the relay, so only the relay needs an open port: no inbound firewall rules, port forwarding or VPN on the machines themselves.
-
Tunnels and sharing
The nfltr client puts a local service, a shell or a file in front of the people and machines that need it.
-
Orchestration
A distributed Claude Code hub: agents run on the laptops, VMs and servers that hold your code, data and access.
-
Relay
The transport under tunnels and orchestration, hosted at nfltr.xyz or run on your own network.
-
Status
Results of the hourly canary that runs the orchestration path against the hosted relay.
Tunnels and sharing
The nfltr client puts a local service, a shell or a file in front of the people and machines that need it.
The nfltr client runs next to a service and keeps one outbound connection to the relay. nfltr http gives a local web app an HTTPS address that works while the command runs and stops when it stops. nfltr tcp forwards SSH, a database or any other TCP protocol, so a machine with no public IP and no open port is reachable from your laptop.
Tunnel commands are end-to-end encrypted by default: with TLS passthrough the relay forwards sealed traffic it cannot read. nfltr wg reaches a private network through one machine on it over WireGuard, with the relay holding no WireGuard key; nfltr p2p moves files and messages directly between machines; nfltr up runs several tunnels from one config file.
curl -fsSL https://nfltr.xyz/install.sh | sh
nfltr config add-api-key
nfltr http 8080 --share
-
nfltr.xyz is served by an nfltr agent
These pages are static files served by
nfltr upthrough the relay, the same path any user's site takes. In a local test the agent hop added no measurable latency: median time to first byte 0.73–0.82 ms over three runs, against 0.76–0.79 ms when the relay served the pages itself.
Orchestration
A distributed Claude Code hub: agents run on the laptops, VMs and servers that hold your code, data and access.
Each machine joins once as a node and sets what its agents may do: which repositories, which tools, and how many agents at once. A Claude session, the hub, takes one goal, starts agents on the machines that have the data or access, runs them in parallel and collects each result.
The hub is a Claude Code session, started by nfltr orch in a terminal or added to your own Claude Code session as an MCP server. Every agent is a Claude Code process on one of your machines. Results survive a closed terminal or a restarted hub and arrive exactly once; the relay carries the messages and runs no model.
curl -fsSL https://nfltr.xyz/install.sh | sh -s -- --with orch
nfltr node join --max-agents 2 --allow-all-tools
nfltr orch "<goal>"
-
From alert to an approved rollback in 1 m 34 s
One measured run on a local Kubernetes cluster: a read-only agent's result named the failing setting 46 s after the alert, and the rollback ran only after the owner signed it. Model spend for the incident session: $0.39.
-
20 tasks on 4 nodes, 5.7× less wall time than serial
One hub, 8 agent slots on a private relay: 1,416 s against 8,106 s of agent time added end to end, and 20 of 20 tasks passed their hidden checks.
-
Eight terminal recordings
Incidents, backlogs and a machine dropping out, recorded on a laptop and cloud VMs joined to nfltr.xyz.
Relay
The transport under tunnels and orchestration, hosted at nfltr.xyz or run on your own network.
Every connection in NFLTR goes through the relay: a share link to a dev server, an SSH session, a hub talking to agents on other machines. Machines connect out to it; it accepts, routes and copies connections. It runs no model and makes no decisions.
nfltr.xyz runs the hosted relay. In beta, the same relay runs on a VM of your own with nfltr relay serve, with your TLS certificate or a pinned self-signed one, so the path between your machines stays on your network. A Go program can embed a tunnel agent and connect to the relay itself with the Go SDK.
curl -fsSL https://nfltr.xyz/install.sh | sh -s -- --with relay
nfltr relay serve --data-dir /var/lib/nfltr-relay --tls-self-signed --tls-name relay.lan
-
Measured against frp, rathole, chisel and bore
Same Docker harness, one CPU each: bulk TCP over 8 streams at 1.26× frp's rate in the final run, and new-connection HTTP at 2.10×. Single-request latency still trails, at 75 % of frp's rate; the post says why.
Status
Results of the hourly canary that runs the orchestration path against the hosted relay.
Every hour a canary starts a fresh hub, joins two nodes through nfltr.xyz, starts an agent on each and a monitor, and checks that every result arrives exactly once and that a pushed branch reached its origin. The agents are a test double, so no model runs.
The status page shows the success rate over the last 24 hours and 7 days, the latest failure reasons, latency and the relay version. One machine runs the canary, so a gap in the runs means that machine was offline; the page marks itself out of date once its newest run is more than two hours old.