Blog
Notes from building nfltr.xyz, which runs AI coding agents where your infrastructure lives.
Each post opens with the problem it is about, belongs to a series, and gives every measured claim one evidence block: the setup, the numbers, how to reproduce it and its limits. The reproduce lines name the commands you can run with the released binaries and the harness (a make target) in the nfltr repository, which is closed source; failed experiments stay in the posts. Each post ends with whether nfltr fits you, where it is not ready, and what to try next.
Using nfltr
Where nfltr fits and where it does not: the problems it is used for, by team size, with what the relay sees and links to the posts that measure each piece.
-
Who nfltr is for: solo developers, startups and organizations
Five problems nfltr solves: private services with no inbound ports, sharing and hosting from your machine, operator access without a VPN, Claude Code agents where your infrastructure lives, and a relay on your own network. For each, the piece that does it, what the relay sees, a minimal example and the measurements, then the trust model and what is not ready.
Distributed Claude Code
Claude Code agents on your own machines, driven by a hub that is your own Claude Code session: how it is built, how it keeps a fleet busy, what it is measured to be good for, and where one agent is still better. Read in order; part 1 first.
-
How distributed Claude Code is built with nfltr
Claude Code's hub-and-subagent model, with agents on all your machines: the design rules, what went wrong while building it, and how we test it without spending on models.
-
How a Claude Code hub learned to fill a fleet
Twenty tasks, eight agent slots, four nodes: what kept slots idle, the 2,048-character limit that hid most of the hub's facts, the fixes, and a full run 5.7× faster than one after another, with what is still partial.
-
What nfltr orch is useful for, measured
One big task split six ways, 20 tasks across a laptop and two cloud VMs, and an incident handled across a cluster, CI and a laptop with the owner's approval: the numbers, their conditions, what is partial, and when one agent is still better.
-
nfltr orch refactored its own CLI
Two runs where a hub and its agents on four nodes split large packages of the nfltr CLI: the root package went from 11,998 to 4,945 lines with no operator code fixes, what the first round's fixes changed, what got slower, and the gaps found.
-
Claude Code agent teams and nfltr orch, measured
The same eight coding tasks run with Claude Code agent teams and with nfltr orch: 8/8 everywhere and no speed winner on one machine; what differs when the lead or hub is killed, on limits, cost reporting and other machines; and what did not go well for nfltr.
-
Build your own agent platform on nfltr
A small web service with no model in it drives the hub over MCP, and Claude Code agents run on your own machines under each one's policy. One recorded developer's day on it, part by part, for $1.18 of model spend, and what the example does not include.
-
Your runs stay on your machine
The dashboard no longer shows orchestration runs: a hub keeps them on its own machine and shows them there with nfltr orch hub runs and nfltr orch hub show, and hubs stay strictly end to end encrypted. The design we built first, why an encrypted hub looked offline, the principle we chose and what it costs.
Services with no open ports
Reaching services behind NAT from remote clients through the connect sidecar, with outbound connections only: the case for an organization, one migration measured end to end, what a gRPC application should set, two home machines (Home Assistant, a GPU box) used from anywhere, a home reverse proxy kept as it is, nfltr beside Tailscale, a home Pi-hole's blocking away from home, and a closing map of all of them. Read in order; part 1 first.
-
Every service reachable from every remote client, with no inbound ports
For organizations with many services and remote clients: one outbound-only layer instead of a port, certificate, VPN route and client code per pair. What developers stop doing, what the platform team stops maintaining, how it holds up through deploys and faults, and the limits.
-
Remote gRPC with no open ports, no VPN and no CA to run
A .NET gRPC fleet moved onto the connect sidecar: public listeners 1 to 0, private CA 1 to 0, a one-line channel change, and a control plane that can now call agents behind NAT by name. How small the migration is, what it costs per call, and the limits.
-
gRPC over the connect sidecar: drop client keepalive, keep deadlines
What a gRPC application should set once its channel runs through the connect sidecar, every claim measured: dead paths found in 15 s with no keepalive, too_many_pings from aggressive keepalive, stuck handlers only a deadline ends, the one hop where keepalive still matters, and liveness and deadlines across several link hops.
-
Home Assistant, reachable from anywhere, exposed to no one
Home Assistant from a phone away from home, without a port forward: open ports at home 2 to 0, configuration 16 lines to 9, the same UI, API and live updates, tested end to end against the real Home Assistant image, with the costs and the gap still open.
-
Your GPU box, reachable from anywhere
A model server on a GPU box at home, used from a laptop anywhere: the usual port forward, dynamic DNS, HTTPS proxy and token against two outbound-only agents with end-to-end encryption. The same time to first token, no open port on the box, a wrong key refused, a restart recovered, and what relaying it costs at list prices.
-
Keep your reverse proxy, drop the port forward
Caddy or Traefik in front of several services at home: keep the routes, the login and the headers, and replace only the port forward with one outbound-only agent. Open ports at home 2 to 0, the visitor's address still first in X-Forwarded-For, forged forwarding headers dropped, measured on both proxies.
-
nfltr alongside Tailscale
Tailscale is a mesh VPN for devices you own; nfltr publishes single services through a relay. Both on one home machine and both at once: the same echo latency, no open port either way, one port instead of the whole machine with a policy or a published service, a password-protected link for someone who installs nothing, and where each one is the better tool.
-
Your Pi-hole, anywhere, exposed to no one
The home Pi-hole's ad and tracker blocking on a laptop away from home, with no port forwarded and nothing answering DNS at home: a VPN home against two outbound-only agents and a stub resolver. Blocking, the admin page, latency, restarts and cost measured on both, and what phones still need.
-
nfltr with the tools you already run
The map that closes the series: Home Assistant, a GPU box, Caddy and Traefik, Tailscale, a Pi-hole and a gRPC fleet, with what nfltr replaced in each, the measured numbers side by side, what the tests left out, and where Tailscale, a VPN or a public name is the better choice.
The relay
The process every connection meets on: running it on your own network, taking orchestration out of it, and the parts of it that are open source. Read in order; part 1 first.
-
Run the relay on your own network (beta)
nfltr relay serve on a VM of your own, so the path between your machines stays on your network: what the relay is and stores, what we checked works (nodes, hubs, your own Claude Code, messages, files) and what the beta does not do yet.
-
Three programs and a relay with no orchestration inside
The relay no longer holds any task state: a mailbox, webhooks into it, content-addressed blobs, presence and typed errors replaced the orchestration code in it. Protocol v1 came as a hard cut, and the CLI became nfltr, nfltr-orch and nfltr-relay behind plugin dispatch. What got smaller, the bugs the split exposed and what is left.
-
Four nfltr repositories are now open source: link, relay, relay-core and a quic-go fork
The link stream multiplexer, the relay's client SDK and wire protocol, the relay's session core and a quic-go fork are public under github.com/nfltr, Apache-2.0 (the fork MIT). What each is, how they fit and what nfltr builds on them, why each starts from a fresh history that still matches go.sum, what stays closed, how to try each, and the limits.
link, the stream multiplexer
The library under the relay's data connections: why it replaced gRPC between replicas and agents, and how its API was designed against the other multiplexers. Read in order; part 1 first.
-
link: why relay replicas stopped talking gRPC
Dead peers found in seconds, a stuck reader that no longer stalls other sessions, and less per-byte overhead: what moving relay data connections from gRPC to a stream multiplexer changed, measured, and where gRPC still fits.
-
Designing a stream-multiplexer API
link v0.9.0 against yamux, smux, quic-go, libp2p, x/net/http2 and net: what Open returns and why half-close matters, configuration, Serve versus Accept, errors, drain, write deadlines and credit, and keeping the v1 surface small. The API decisions with real signatures, and the trade-offs link accepted.
nfltr on nfltr
Running our own sites, releases, access and monitoring through nfltr, and the bugs that found. Read in order; part 1 first.
-
nfltr.xyz now runs on nfltr
Our public sites are served by one ordinary nfltr agent serving static directories through the relay, which keeps only sign-in, the dashboard, the API and shares: the routing and apex split, atomic publish and rollback, what we measured, the ownership bug that took the first site down, and the limits.
-
One YAML file, three sites
nfltr.xyz now presents tunnels and sharing, orchestration on orch.nfltr.xyz and the relay on relay.nfltr.xyz. The homepage, the shared header and footer and which page lives on which host come from one validated YAML file; how pages moved without breaking old URLs, how nfltr serves and publishes the sites, why not Hugo, and what the file drives now and what stays code.
-
nfltr on nfltr, part 2
A status page built from the hourly canary, operator access to the production VM through nfltr with the cloud provider's SSH kept for emergencies, a Linux node on a Mac, and releases run by a hub with every production step approved by Touch ID. The three bugs the first hub-run release found, and the release that ran every step ok.
-
Relay metrics on a laptop, through nfltr
Prometheus and Grafana on a laptop scraping a remote server's /metrics through an owner-only nfltr agent and nfltr tcp-connect: no open port, and the data stays local. A trimmed compose file and prometheus.yml for any Prometheus endpoint, and why per-agent labels must be summed before they are dropped.
How we build nfltr
How we measure, test and release nfltr, with the evidence and the failures: the relay measured against other tunnels, the relay soaked as several replicas on Kubernetes, and the whole process. Read in order; part 1 first.
-
A faster, leaner relay, measured against frp, rathole, chisel and bore
One Docker harness, four open-source tunnels, seven rounds of work: how we measured, the bugs we found (lost response bytes, a 100-agent wall, a settings lookup that copied every flag, a relay crash found by a conformance suite), what changed up to a thin data plane on both legs, what we threw away, and where nfltr still trails.
-
The relay as several replicas on Kubernetes
Three relay replicas behind one Service, 52 agents and a fault every 20 minutes for 6 hours. What assumed one process, how a visit crosses replicas, why the first long run failed (stale agent records), the run that passed after the newest session of an agent started to win, and the limits that remain. nfltr.xyz stays on one VM.
-
How we build reliable Go software: the process and its evidence
The layers and what each guarantees, tests that wait for events instead of time, porcupine on the task stores, third-party conformance suites with their open findings classified, injected network faults, benchmark methods and a performance ledger, production signals, a release process that ships only green commits, and what our scale evidence does and does not show.