When to use NFLTR
NFLTR is a distributed AI work runtime: a planner assigns explicit task contracts to workers through a live DAG with optional review, summarization, finalization, and custom task-mode phases, plus inline human-in-the-loop approvals and a hosted control plane you don't have to operate. This page is the honest decision guide for whether it fits your workflow.
Use NFLTR when
- You want a goal in English ("prepare a launch readiness packet across docs, ops, and security evidence") to fan out into parallel, contract-tagged worker tasks with explicit review gates — not just a single agent looping in a chat.
- You need approvals or rejections to land on specific tasks in a DAG, not buried in chat scroll. The dashboard surfaces each pending decision inline.
- Different task contracts need to run on different machines (e.g. one worker has GPU access, another has production logs, and a third only reviews evidence). Workers connect outbound to the control plane; no inbound firewall rules.
- You want provenance attributed truthfully — per-task model, reasoning effort, worker, artifacts, and commit metadata stay attached to the task that produced them.
- You want a durable, replayable audit trail. Every dispatch, event, approval, and merge is recorded against an orchestration root the dashboard can render later.
Don't use NFLTR when
- One agent in one chat session, on one machine, finishes the job end-to-end. The orchestration overhead isn't free.
- You need a low-latency HTTP proxy or tunnel — that's a different shape (look at ngrok, cloudflared, tailscale-funnel).
- You can't authorize an outbound TLS connection from your worker hosts to a hosted control plane (and don't want to run your own — see the self-hosted section below).
- The work has no useful review, reduction, integration, artifact handoff, or audit boundary. NFLTR's value compounds when those gates exist; without them it's just an SSH-out-of-band shell.
Hosted vs. self-hosted
Hosted (nfltr.xyz) | Self-hosted | |
|---|---|---|
| Operate the control plane | No — we run it | Yes — one GCE VM running rpc-server under systemd (standalone VM deployment with Caddy + OPA) |
| Sign in | Google OAuth | Same code, your own OAuth client (or none, for localhost-only) |
| Where task execution runs | Your machines, outbound to nfltr.xyz:443 |
Your machines, outbound to your VM |
| Bring your own Anthropic key | Yes (or claude login OAuth) |
Same |
| Multi-tenant audit | Built in | Built in |
| Cost | Free during preview | Your infra cost |
Switch to self-hosted when your data residency, audit boundary, or air-gap constraints actually require it — most early users don't need that. When you do self-host for production, the recommended shape is a standalone VM (one GCE VM running rpc-server under systemd). Dashboard, landing, and docs ship via the embedded web/ tree inside that binary — rebuild the bundle and reinstall. Kubernetes, Helm, GKE, and make deploy-ui are legacy / non-production control-plane paths — do not use them for production deploys.
Decision shortcut
Try nfltr quickstart first. It runs a tiny verified orchestration in under two minutes and gives you a hands-on read on whether the operator surface matches how you want to work. The five-minute walkthrough covers the next steps.
Next steps
- Getting Started — hosted path from account to first dispatch
- Multi-Agent Orchestration — planner-worker workflows and parallel slices
- Agent Orchestration — hosted product overview