Keep NetBox as your source of truth. Let rConfig capture the operational state. Reconcile both, every day.

If you run NetBox, you already know what it’s for. IPAM. DCIM. Rack layouts. Cable maps. VLAN models. Circuit inventories. Custom fields and config contexts that encode your team’s intent down to the interface. It’s the single piece of infrastructure most network engineers would refuse to live without.

NetBox holds intended state. What it does not hold, and was deliberately never designed to hold, is the running configuration of every device. That’s out of scope by design, and the project maintainers have been clear about it. Search the NetBox community forum for “config backup” and you’ll find years of threads where the answer is always the same: use something external, point it at NetBox’s API, and let the two systems do their own jobs.

rConfig is the “something external.” Vendor-agnostic. 200+ device profiles out of the box. Installed on-prem, VM, bare metal or private cloud. Your NetBox inventory becomes rConfig’s device list over the API, and every running-config on every device lives in rConfig’s versioned archive from that point forward.

rConfig doesn’t install a NetBox plugin. Doesn’t run inside the NetBox process. Doesn’t touch the NetBox database directly. All of its interaction with NetBox happens over the documented REST API, through a read-only token that you scope yourself. That matters because it means rConfig cannot destabilise your NetBox deployment, cannot compete with NetBox for worker capacity, and cannot be the thing that breaks when you upgrade NetBox.

What rConfig does is what NetBox deliberately does not: capture running configuration, track how it changes, and prove what it looked like when someone needs to know. Self-hosted on-prem, VM or bare metal, or in your private cloud. Compatible with NetBox, NetBox Cloud and NetBox Enterprise. Your ops team is running it inside 30 minutes on V8 Pro or Vector. Many teams run NetBox alongside Zabbix and Nautobot; rConfig consumes each of them the same way it consumes NetBox.

If you’re in scope for NIS2 or DORA, the regulators want two different types of evidence. They want to know how the network was configured, and they want to know whether what you actually deployed matches what your documentation said you deployed. NetBox answers the second question on its own (that’s what a source of truth is for). rConfig answers the first one and reconciles both.

Run both and your compliance team stops chasing the NOC for screenshots at 4pm on a Friday. Drift-detection policies run automatically, every day, against every NetBox-managed device. When the auditor asks what the ACL on the core router looked like on 12 March, the evidence is already in rConfig’s archive, already cross-referenced against NetBox’s intended-state record for that device.

The NetBox ecosystem has real options for configuration backup. This page exists because none of them are right for every team, and most of the engineers reading this have already tried at least one of them.

netbox-config-backup is DanSheps’ open-source NetBox plugin that backs up devices into a Git repository using NAPALM. It’s well-written, it’s free, and it runs inside NetBox. That last point cuts both ways. You don’t have a separate system to manage, but you do have a backup workload competing with NetBox’s own resources, and an upgrade to NetBox means an upgrade to the plugin as well. Fine for small estates. Gets awkward above a few thousand devices or when compliance reporting enters scope.

Nornir plus NAPALM plus Ansible driven by NetBox inventory is the NetDevOps canonical answer. It works. It’s also a stack that requires ongoing Python, Jinja and Git skill on the team. When the engineer who built it moves on, the stack becomes technical debt. We see this play out about twice a quarter.

Netpicker’s NetBox plugin is a commercial alternative. Good tool, good team behind it. The main differences: rConfig predates them by more than a decade, has a larger installed base in regulated industries (government, finance, critical infrastructure), ships with pre-built NIS2 and DORA reporting templates, and includes bulk configuration deployment and firmware management as first-class features rather than separate products.

rConfig’s positioning is simple. If you want an NCM platform that consumes NetBox cleanly, comes with the compliance reporting your auditor expects, and doesn’t ask your network team to learn Python to operate it, this is the tool. If you want to build your own stack and you have the engineering capacity to maintain it, Nornir is a fine choice and we’ll still be here if things change.