Who nfltr is for: solo developers, startups and organizations
Most of the posts on this blog measure one piece of nfltr in depth. This one is the map: which problems nfltr is used for, which piece does each, what stays on your machines and what the relay can see, and where it is not ready. It is written for anyone deciding whether nfltr fits: one developer with a laptop and a home server, a startup with a few services and machines, or a platform or operations team.
The problem
The machines that hold the work are rarely the ones that can be reached. A dev server runs on a laptop, a database sits behind a home router or a customer's NAT, a build box or a staging VM has a closed firewall, and the cluster and CI that hold the answer to an alert are reachable only from inside their own networks. The usual fixes are an inbound port with a DNS name and a certificate, a VPN or a bastion host, or copying data to where the tool runs. Each one is something to open, renew, patch and defend, and each grows with every new machine.
nfltr takes one approach to all of these: every machine connects out to a relay, and the relay connects them to each other inside one account. Nothing accepts a connection from the network. The relay is the hosted one at nfltr.xyz, or one you run on your own network (a beta). What runs on top of that connection is what differs between the five uses below.
At a glance
| Problem | nfltr piece | Guide | Measured in |
|---|---|---|---|
| Reach a private service from remote clients, with no inbound port | The connect sidecar: nfltr up with connect:, nfltr dial, end-to-end pins |
nfltr up, nfltr dial | Every service reachable, Remote gRPC, keepalives and deadlines, against frp and others |
| Share a local app, a log or a file; host a static site | nfltr http, nfltr share, nfltr tail, nfltr a2a |
Share a local app, Share a log, Send files and messages | nfltr.xyz runs on nfltr, One YAML file, three sites |
| Operator access with no VPN or bastion | nfltr shell, nfltr tcp-connect, nfltr wg, an owner-only nfltr up agent |
SSH behind NAT, Reach a private LAN | nfltr on nfltr, part 2, Relay metrics on a laptop |
| Claude Code agents on the machines that hold the work | nfltr orch: nodes, a hub in your own Claude Code, owner-signed approvals |
Join machines as nodes, Alert to approved fix, Build your own agent platform | Distributed Claude Code, What orch is useful for, Agent platform, Your runs stay on your machine |
| Keep the path between your machines on your network | nfltr relay serve (beta) |
Run your own relay | Run the relay on your own network |
The numbers this post quotes come from those posts; each has its own evidence blocks with the setup and how to reproduce it. They are collected here:
Evidence: the numbers quoted in this post
- Setup
- Each number is copied from the evidence block of the linked post, where its setup is described in full. Most are one or two runs on one host (Docker containers or processes on one laptop); the agent results are one or two runs of real Claude Code agents on joined machines.
- Numbers
- A .NET gRPC fleet moved onto the connect sidecar: non-loopback listeners 1 → 0, private CAs 1 → 0, 0.1 to 0.3 ms more per call at p50 through two sidecars and the relay (Remote gRPC). Against frp on one CPU per process: bulk throughput 1.13× (one stream) and 1.26× (eight streams), 1 MiB responses 0.83×, 175 against 126 KiB of relay memory per idle tunnel (the comparison). A static site through an agent: time to first byte 0.76 s against 0.79 s served by the relay itself, agent at about 40 MB (nfltr.xyz runs on nfltr). An idle joined Linux node: under 1 % CPU and about 10 MB (part 2). One big task: hub 322 s against one agent's 605 s, at 1.57× the cost; 20 tasks over three machines in 3.5× less time than serial, with slots 0.39 busy; an alert to an owner-approved rollback in 1 min 34 s (What orch is useful for).
- Reproduce
- Each linked post's evidence block names its commands: what you can run with the released binaries, and the harness in the nfltr repository, which is closed source.
- Limits
- The limits of each source apply: one host means no real network distance or loss, and one or two runs are no distribution. Nothing here is a measurement of your workload.
By team size
The five uses are the same at every size; what changes is which ones matter first and who operates what.
| Solo developer | Startup | Organization | |
|---|---|---|---|
| Services with no inbound ports | A database or API on a home server, used from a laptop | Services across a few clouds and offices; edge or customer-site agents behind NAT; the same mapping file on laptops and in CI | One connectivity layer instead of a port, certificate, VPN route and client code per service and client |
| Share and host | A dev server or log shown to someone for an hour | Review links, webhook endpoints, a docs site served from a machine you control | Shares as the controlled way anyone outside the account reaches a service |
| Operator access | SSH to a box at home; a NAS on the LAN | Staging and production shells and metrics with no VPN or bastion, the provider's console kept for emergencies | Owner-only access agents that dial only the loopback ports in their file |
| Agents | Claude Code agents on your own spare machines, started from your Claude Code | Agents on build boxes and staging, an investigation on a failed CI run | Node policies set by each machine's owner, owner-signed grants for production steps, your own platform over the hub |
| Your own relay (beta) | Rarely needed | When traffic between your machines must stay on your network | Where policy requires it, with the beta's limits below |
A solo developer operates nothing: the relay is hosted, and every command is a process you start and stop. A startup typically adds a sidecar per machine and a few nodes. An organization owns the account keys, the node policies and, if it chooses, the relay.
1. Reach private services with no inbound ports
The problem. A client needs a service on another network: a gRPC control plane calling agents at customer sites, a laptop reaching a database at home, a CI job reaching a staging API. Each pair needs a port, a DNS name, a certificate, often a VPN route, and connection code in each client's language.
The piece. The connect sidecar. On the service's machine, nfltr up publishes services under an agent name. On the client's machine, a connect: mapping in the same kind of file gives each remote service a local endpoint (a loopback port or a unix socket), and the application connects there as if the service were local; a script can open one session with nfltr dial. The sidecar keeps the connection alive, reconnects, and fails a call at once with a typed reason instead of hanging.
What stays yours, and what the relay sees. The services never listen on the network. With e2ee: true and the pin the agent prints, the two sidecars run TLS 1.3 inside the session and accept only that certificate, so the relay carries ciphertext; a relay that swaps in its own key fails the handshake. The relay still sees which agent and service, when, and how many bytes. Without a pin, it can read the bytes unless the application runs its own TLS. Retries, idempotency and authorization of your own calls stay in your code.
A minimal example. On the service's machine:
# home.yaml
agent: home
services:
db: { tcp: 5432, e2ee: true }nfltr up -c home.yamlOn the client, with the pin it printed:
# app.yaml
connect:
db: { target: home/db, listen: "127.0.0.1:5432", pin: "<pin>" }nfltr up -c app.yaml
nfltr dial home/db --pin <pin> < query.bin > answer.binRead next. Every service reachable from every remote client for where it fits and the scale-out soak, Remote gRPC with no open ports for a .NET fleet's migration, gRPC keepalives and deadlines for what a gRPC client should set, and the relay against frp, rathole, chisel and bore for throughput, where nfltr leads and where it trails.
2. Share and host from your own machine
The problem. Someone needs to see what runs on your machine: a dev server for review, a log as it grows, a file, a static site. Deploying it somewhere, or opening a port, is more work than the thing is worth.
The piece. nfltr http gives a local port or directory a share URL that works while the command runs; nfltr share, nfltr tail and nfltr watch do the same for a snippet, a growing file or a command's output. nfltr a2a, nfltr notify and nfltr clipboard move files, messages, notifications and clipboard text between your own machines with no public link at all. nfltr up serves several sites from one agent: nfltr.xyz, orch.nfltr.xyz and relay.nfltr.xyz are static directories served this way by an ordinary agent through the relay.
What stays yours, and what the relay sees. The files and the app stay on your machine, and a link stops the moment you stop the command or goes 24 hours without a visit (--share-ttl sets another time). nfltr http ends the visitor's TLS on your machine by default (verified mode). The relay sees requests when you choose --mode inspectable or a feature that needs them, such as --allow-path. a2a and notify messages between your machines are end-to-end encrypted by default; a pairing key makes them resist a relay that swaps keys.
A minimal example.
nfltr http 8080
nfltr http ./public
nfltr share ./app.log --expire 30mRead next. Share a local app, Share a log or command output and Send files and messages; nfltr.xyz now runs on nfltr and One YAML file, three sites for hosting sites this way, with the limits: no custom host names for accounts, no redirects, one rate budget per agent.
3. Operator access without a VPN or bastion
The problem. You need a shell on a machine with no public IP or a closed firewall, a NAS or admin page on a private LAN, or a server's metrics on your laptop. A VPN or a bastion host is one more service to run and patch, and an open SSH port is one more thing to defend.
The piece. nfltr shell runs an SSH server reached through the relay, and nfltr ssh-config lets your laptop's ssh use it; nfltr tcp and nfltr tcp-connect tunnel any one port. nfltr wg serve makes one machine on a LAN a WireGuard exit that forwards only to the destinations you allow, and nfltr wg socks5 or nfltr wg connect reaches them from a laptop. nfltr.xyz itself is operated this way: an owner-only nfltr up agent on the production VM with two TCP services, the VM's own sshd and the relay's metrics, forwarded to loopback only, with the cloud provider's SSH kept for emergencies.
What stays yours, and what the relay sees. sshd (or the embedded server's authorized keys) still authenticates every session, and SSH is encrypted end to end, so the relay sees ciphertext. WireGuard tunnels are sealed between the laptop and the exit; the relay holds no WireGuard key. Only keys of your account reach your agents, and an agent dials only the targets in its own file.
A minimal example.
nfltr shell --name build-box --authorized-keys ~/.ssh/authorized_keys --host-key ~/.ssh/nfltr_host_key
nfltr ssh-config build-box --identity ~/.ssh/id_ed25519
nfltr wg serve --name home-lan --allow "$LAN_IP:8080"
nfltr wg socks5 home-lan --listen 127.0.0.1:1080Read next. SSH to a machine behind NAT and Reach a private LAN; nfltr on nfltr, part 2 for the access agent and its sandbox, and Relay metrics on a laptop for Prometheus and Grafana on a laptop through nfltr tcp-connect.
4. Agents where your infrastructure lives
The problem. A coding or operations task needs a machine your Claude Code session is not on: data that should stay on a VM, a cluster or CI reachable only from inside, more agent slots than one laptop has, or work that must keep running after your terminal closes.
The piece. nfltr orch. Each machine joins once as a node; it starts Claude Code agents on demand and stops them when the work ends. Your own Claude Code session becomes the hub: it lists the nodes, spawns agents on the machines it chooses, steers, continues and stops them, and receives every completion exactly once, also after it was closed and reopened. A hook delivers an alert or a GitHub event to the hub, which can send read-only agents to the cluster, CI and a VM and propose one fix as an exact prompt for one machine. A node's tool policy can deny a command unless the owner signed a grant for that exact prompt on that node, for one turn. The same hub runs nfltr's own releases, each production step behind such a grant. A service of your own, with no model in it, can drive the hub over MCP to give your teams a task box or a webhook.
What stays yours, and what the relay sees. Repositories, data and credentials stay on the nodes: agents clone and push with the node's git credentials, and Claude Code calls its model provider from the machine it runs on. Assignments, prompts and results between hub and agents are end-to-end encrypted by default. The hub's record of its runs stays on the hub's machine; the relay sees only whether it is online, and the dashboard shows no runs. Your approval signing key never leaves your machine, and the relay cannot forge a grant.
A minimal example. On each machine that runs agents, then in your Claude Code:
nfltr start
claude mcp add nfltr -- nfltr mcp --toolset hubnfltr start joins the machine with a policy under which agents read freely and change files or run commands only in a turn you approved. A production machine with its own policy and your approval key:
nfltr node join --max-agents 2 --labels env=k8s-prod --tool-policy-file k8s-policy.json --approval-public-key nfltr-approval-pub-v1:...Read next. Join machines as nodes, Use nfltr from Claude Code, From alert to approved fix and Build your own agent platform; How distributed Claude Code is built for the design and its fault tests, What nfltr orch is useful for, measured for where a hub is faster and where one agent is better, Build your own agent platform for a recorded day on the example service, and Your runs stay on your machine for where run records live. For a quick command on a machine you already reach, SSH is simpler.
5. Run the relay on your own network (beta)
The problem. A requirement says the traffic between your machines must not leave your network, or you need to inspect it there.
The piece. nfltr relay serve runs the relay on a Linux VM of your own, with your TLS certificate or a pinned self-signed one; one nfltr config set-relay step points each machine at it. Nodes, a hub in your Claude Code, orch task commands, messages, notifications, files, SSH and TCP tunnels work against it. Its operator can require, allow or forbid end-to-end encryption of TCP sessions to services, for example to inspect traffic for compliance, and every session reports whether it is encrypted.
What stays yours. The relay, its data directory and its API key are yours; nfltr.xyz is not on the path.
A minimal example.
nfltr relay serve --data-dir /var/lib/nfltr-relay --tls-self-signed --tls-name relay.lanthen the set-relay line it prints, on each machine.
Read next. Run your own relay (beta) and Run the relay on your own network, with what is not supported yet: share links, WireGuard, the dashboard, failover and automatic certificate renewal.
Building on nfltr
Four repositories under github.com/nfltr are open source, Apache-2.0 except the quic-go fork (MIT). The nfltr CLI, orchestration and the relay server that nfltr.xyz runs are built on them and stay closed.
- nfltr/relay: the wire protocol and the Go client SDK.
agentexposes a local HTTP service through a relay from inside your own program, with no separate binary;rpcclientcalls it from another program on the same account.mailboxclientappends to, pulls and acknowledges an account's mailboxes and manages webhooks into them;presenceclientlists an account's agents and waits for them to come and go;relayblobuploads and downloads content-addressed blobs, resumable and verified by SHA-256;p2pandwgare the clients for peer-to-peer sessions and WireGuard tunnels.go get github.com/nfltr/relay/client@latest. - nfltr/link: the stream multiplexer under the sessions. Many byte streams, each a
net.Connwith its own flow control, over a connection you dial and secure, so a stalled reader holds only its own stream; QUIC and gRPC transports behind one interface; andlinkvet, ago vettool that finds sessions left open and read loops with no deadline.go run github.com/nfltr/link/examples/quickstart@latest. - nfltr/relay-core: the relay's session core as a library and a small command that runs one relay: one replica, a key file or your own identity provider, no database. A relay whose code you can read and change, and a test helper for programs that talk to one.
What each contains, how they fit and how to try them: Four nfltr repositories are now open source.
The trust model
- Outbound only. No machine accepts a connection from the network; every machine connects out to the relay.
- The account is the boundary. The relay derives identity from the API key, never from what a client claims, and an account's key reaches only that account's agents. It stores API keys only as hashes. Anyone outside the account reaches your services only through a share you start.
- The relay always sees metadata. Your account, machine names, labels and capabilities, which machine talks to which, when, and the size and timing of traffic.
- Content depends on the path. End to end by default: messages between hub, nodes and agents,
a2aandnotify,nfltr httpshares in verified mode, WireGuard tunnels. End to end when you ask: connect-sidecar sessions with a pin. Readable at the relay: rawnfltr tcpbytes unless the protocol inside is encrypted (SSH is), sessions without a pin, and shares in inspectable mode. - Pairing keys close the remaining gap. Without one, the first message to a peer is encrypted to a key the relay vouches for, so a relay that swapped keys would not be detected. With the same pairing key on your machines, it cannot complete the handshake. A pairing key proves a peer holds the key, not which machine it is.
- Never sent to the relay. Git credentials, Claude tokens and your approval signing key.
- Approvals are checked by the node. A grant covers one exact prompt on one node for one turn, checked against your public key; the prompt has no say, and the relay cannot forge one.
The full threat model, with what is not guaranteed: Architecture and guarantees.
Not ready for
- High availability of the hosted relay. nfltr.xyz runs its relay as one process on one VM, so a deploy is a short gap that clients ride out. Several replicas are measured on a test cluster only.
- Agents other than Claude Code.
nfltr orchruns Claude Code agents only. - Production use of your own relay without testing it yourself. It is a beta: one process, no failover, no share links, WireGuard or dashboard, no automatic certificate renewal, no Windows host.
- Reading or changing the client and server. The
nfltrCLI, orchestration and the relay server are closed source; link, the relay SDK and protocol, and relay-core are open. - Teams with roles. Several people can share an account's key and nodes, each with their own hub, but there are no organizations, roles, single sign-on or per-machine identity at the relay: whoever holds an account key reaches the whole account.
- Spreading one service over several agents. Put a load balancer behind one agent.
- A price. nfltr.xyz has no published pricing.
- Windows in production without your own testing. Windows code has Windows-only tests but no Windows CI runner yet.
Is it for you?
Fits if your work lives on machines you cannot or do not want to open to the network (a home server, a laptop, a build box, a staging VM, a customer site, a cluster) and you want services, shares, shells or Claude Code agents to reach them with no inbound port, no VPN and no certificate authority, with content end to end where the table above says so.
Not ready for the cases in Not ready for: high availability on the hosted relay, agents other than Claude Code, a production relay of your own without your own testing, teams that need roles or single sign-on, and published pricing. For a quick command on a machine you already reach, SSH is simpler; for a quick fix in one repository, one Claude Code session is faster than a hub.
Try next: install nfltr and sign in, then the guide for the problem you have:
curl -fsSL https://nfltr.xyz/install.sh | sh
nfltr config loginWhen to use nfltr is the same map as a decision guide. Then Share a local app, SSH to a machine behind NAT, the nfltr up reference for the connect sidecar, Join machines as nodes for agents, or Run your own relay.