Why dflux Runner

dflux Runner drives deterministic protocol procedures over NGAP, Diameter, SBI, REST, and PFCP — plus GTP-U user-plane traffic — against real or simulated cores. It is not a network function. The sections below tell you whether that fits your problem.

When to pick dflux Runner

Pick dflux Runner when:

• You need a deterministic test, not a working NF. Conformance and negative tests want to know exactly which messages went out, which checks passed, and which final state the run landed in. A real AMF or HSS gives you a black box; dflux Runner gives you the script.
• You drive multiple protocols on the same UE. A test that registers a UE over NGAP and validates the parallel S6a profile fetch over Diameter is one flow. Two separate tools means two test suites that drift apart.
• You need both load and conformance from one model. The same registration flow runs as a single-UE conformance check or as a 1000-UE/s burst — same YAML, different -rate and -repetitions.
• You want to gate CI without standing up a tester binary. A static Go binary, an exit code, and a JSON report are everything CI needs. No JVM, no Python virtual environment, no lab-only appliance.
• Your tests live in version control next to the code they exercise. Flow YAML diffs cleanly in pull requests, and a new flow is copy-paste-edit from a sibling.

When not to pick it

Pick something else when:

• You need a working network function in production. The shipped registration_amf flow is a wiring stub. Real AMFs implement the full registration state machine; dflux Runner implements whichever subset your test declares. Run Open5GS, free5GC, or a vendor AMF for production.
• You need every 3GPP procedure out of the box. The catalog covers the common procedures; less common ones — mobility-restriction-list updates, AMF status indication, UPF F-TEID lifecycle nuances beyond a single setup — need authoring. The schema makes that tractable, but it is not click-once.
• You have no 3GPP-aware author on the team. Flow YAML uses 3GPP terminology directly — TACs, GUAMIs, SUPIs, NAS PDUs. Nothing hides the protocol from the author.
• You need a GUI-driven recorder and replayer. This is a CLI- and YAML-first tool. The web UI browses reports; it does not author tests.

What it replaces

Most teams arrive with an existing approach. Here is how dflux Runner maps onto the common ones:

Strengths

• Deterministic dispatch. Every event maps to exactly one transition. A passing test means the procedure took the path you specified — not something close to it.
• One catalog, every protocol. Adding NGAP coverage uses the same tool as adding Diameter coverage. The catalog ships hundreds of flows and suites across NGAP, SBI, REST, PFCP, and Diameter — browse the flow and suite catalog.
• Load and conformance from one definition. The flow is the test; the workload knobs are orthogonal to it.
• CI-shaped output. The CLI exits 0 when every check passes and non-zero otherwise, and can emit JSON or JUnit via -output / -output-file. No interactive prompts.
• Single static binary. No runtime to install and no language ecosystem to manage; drop it on the host and run.

Limitations to know about up front

• Authoring requires 3GPP fluency. Flow YAML names protocols and field paths directly.
• Server-mode flows are stubs. The shipped server-mode flows validate wiring; full responder implementations are case-by-case authoring.
• The DPDK user-plane needs privileged setup. Huge pages, NIC binding, and CAP_SYS_ADMIN. Userspace mode runs anywhere but caps at a few hundred kpps.

Where to go next

• Overview — what ships, how it is used, and what it is not
• Quickstart — build, run a flow, and read a report in about ten minutes