When to Use NFLTR
Use this page to choose the right starting path: hosted orchestration on nfltr.xyz, a self-hosted NFLTR control plane, or a transport-first operator path.
Choose your default path
| Path | Choose it when | Next step |
|---|---|---|
| Hosted orchestration | You want the hosted control plane, dashboard visibility, guided docs, and planner-worker workflows on nfltr.xyz. | Agent Orchestration |
| Self-hosted control plane | You need your own deployment boundary, operator-controlled infrastructure, or standalone rollout path before you onboard planners and workers. | Standalone VM deployment guide |
| Transport-first operator path | You mainly need stable identities, verified routes, browser terminals, or secure sharing before the broader orchestration story. | CLI Reference and Dashboard |
Not all connectivity problems look the same
Some teams start with hosted orchestration and dashboard visibility. Others need a self-hosted boundary first. Others still begin with transport, remote access, or operator workflows. NFLTR covers all three, but you should choose the path deliberately instead of treating every mode as the same onboarding story.
Choose NFLTR when you want stable identities, verified routes, operator workflows, and one platform that can support hosted orchestration, self-hosted operation, and transport-first access without changing products.
Where NFLTR is strongest
| Need | Why NFLTR is strong |
|---|---|
| Self-hosted control plane | Single-binary self-hosting for simple deployments, plus Redis/Postgres-backed multi-pod operation for larger environments. |
| More than HTTP tunnels | HTTP, gRPC, raw TCP, WireGuard, agent-to-agent messaging, P2P, browser terminal, and embedded SSH all live in one platform. |
| Stable identities | Agent IDs are first-class identities, not disposable random URLs. |
| Verified-route security | NFLTR supports agent-terminated TLS, WireGuard, and E2EE A2A paths where the NFLTR relay forwards opaque encrypted data. |
| Verifiable trust | TLS fingerprints, combined identities, and the append-only transparency log give users a way to verify relay claims. |
Where NFLTR still asks more from you
NFLTR is not a zero-decision product. It assumes you care about route naming, identities, policies, and trust boundaries.
- You will spend more time on DNS, certificates, or verified domains when you want stable public hostnames.
- The product surface is broad, so choosing the right mode matters.
- Operator-facing features are stronger than throwaway preview ergonomics.
That is a deliberate trade: more control, more explicit trust boundaries, and less magic.
Choose NFLTR when...
- You need stable machine identities instead of disposable URLs.
- You want one control plane for web services, TCP tunnels, VPN-style access, and operator workflows.
- You care about whether the relay can inspect traffic, not just whether traffic is encrypted in transit.
- You need stable machine identities, fleet labels, and programmable policy instead of anonymous throwaway URLs.
- You want a path from homelab deployment to clustered production deployment without replacing the tool.
NFLTR is probably not the right fit when...
- You only need an instant public URL for a local dev server and do not care about self-hosting.
- You want a full private network mesh with direct peer-to-peer connectivity as the primary abstraction.
- You care more about "no setup at all" than about trust boundaries, policy, or protocol breadth.
What NFLTR is improving right now
The biggest product gaps are no longer missing transport primitives. They are packaging and operator UX.
| Focus | Why it matters |
|---|---|
| Route catalog + domain onboarding | Show every stable, public, and E2EE entry point for an agent in one place, with configuration hints. |
| Public E2EE proof UX | Turn fingerprints and transparency data into a shareable trust story for end users. |
| Explicit tunnel modes | Make the difference between verified, inspectable, and private-share tunnels obvious. |
The dashboard now includes a per-agent route catalog showing stable browse URLs, share URLs, direct wildcard hostnames, and verified E2EE hostnames, plus inline guidance when the required domain settings are not configured yet.
A useful way to think about NFLTR
NFLTR is an operator-controlled identity and relay layer that can expose services, connect agents, open browser terminals, and make more explicit trust claims about encrypted traffic.
Next steps
- Agent Orchestration — start the hosted planner-worker path.
- Standalone VM deployment guide — start the self-hosted operator path in the repository docs.
- Dashboard — see the admin UI, traffic inspector, browser terminal, and agent inventory.
- End-to-End Encryption — overview of TLS passthrough, WireGuard, and proof material.
- E2EE Whitepaper — deeper architecture and threat model.
- Share URLs — public sharing, wildcard domains, and access controls.