Why dflux TinyCore

The problem

Other open-source cores are powerful and standards-rich, but getting one running for a lab is often a project in itself: many network functions to configure, a tangle of YAML and SBI endpoints to line up, and a learning curve before you even see a UE register. When all you want is a real core to attach a gNB or UE simulator to — to learn, to test against, or to prototype an integration — that overhead gets in the way.

The answer

dflux TinyCore trims the setup down to the essentials:

• Four core processes instead of a dozen — DMF (AMF+SMF), DPF (AUSF/UDM/UDR/PCF), NRF, and UPF — plus optional NSSF and SMSF when you need them. See Network functions.
• One docker lab that wires the core together on a single bridge network, ready for a gNB simulator to connect over real NGAP/SCTP.
• A real golden path — UE registration, 5G-AKA authentication, PDU session setup, and user-plane forwarding all run, not stubbed.
• In-memory or persistent stores — run fully in memory for a throwaway lab, or back the NRF and DPF with SQLite/Postgres when you want state to survive a restart.

What it's good for

• Learning 5G — watch a registration and a PDU session happen end to end, with the 3GPP interfaces laid out plainly.
• Lab testing — point a test suite at a real core that boots in seconds and tears down cleanly.
• Prototyping integrations — bring up a gNB, UE, or UPF datapath and validate it against a working control plane.
• Demos — a self-contained core you can run on a laptop without dedicated hardware.

Honest about scope

dflux TinyCore is a lab and learning core, not a carrier-grade product. It runs a single PLMN and a single AMF, and it does not do handover, roaming, or multi-AMF mobility; the PCF is minimal. NSSF and SMSF are optional lab add-ons. Subscriber provisioning is seed/SQL-based today — there is no admin REST API. These are deliberate trade-offs that keep the core small and easy to reason about.