Keep NetBox as your source of truth. Let rConfig capture the operational state. Reconcile both, every day.
rConfig consumes your NetBox inventory over the REST API, backs up the running configuration of every device on your schedule, detects drift between NetBox’s intended state and the network’s operational state, and generates NIS2 or DORA evidence without another inventory to maintain, without a plugin to install in NetBox, and without a Python pipeline waiting to break.
NetBox 3.x and 4.x. Filter by site, tenant, role, platform or tag. One way, API only integration.
Works with NetBox, NetBox Cloud and NetBox Enterprise. Documented integration since 2023. Read the source of truth deep dive on our blog
NetBox models your network. It was never meant to back it up.
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.
- NetBox doesn't back up running config. Never has. Not in scope.
- The DanSheps netbox-config-backup plugin works well, but runs inside the NetBox process and competes with NetBox's own resources.
- Nornir plus NAPALM plus Git is a legitimate stack, if you have a Python capable engineer who can own it.
- Netpicker's NetBox plugin is a real alternative. We cover where rConfig fits differently in the competitive section below.
- Ansible driven backups work until the playbooks drift from the devices they're supposed to back up.
rConfig consumes NetBox the way NetBox wants to be consumed: over the API, one way, no plugins to install in NetBox itself.
NetBox plus rConfig, in three moves.
NetBox defines the intent. rConfig captures the operational reality. The two systems, read end to end, leave no gap for an auditor to find.
Sync
NetBox devices become rConfig devices automatically, scoped by site, tenant, device role, platform, manufacturer, tag or status. Add a device to NetBox, it lands in rConfig on the next schedule. Retire one in NetBox, it's flagged in rConfig for review before anything breaks.
Capture
Every running config, every startup config, every change, stored and diffable. 200+ vendors out of the box. No per vendor plugin to maintain. No Jinja templates to author. No NAPALM version pinning.
Prove
Compliance policies run against every NetBox managed device. NIS2, DORA, PCI-DSS, CIS benchmarks and anything your security team writes. Compare operational state against NetBox's intended state for drift detection. Evidence exports in minutes.
How rConfig consumes NetBox, step by step.
Five screens. Ten minutes for a single site pilot. Filter and mapping that scales cleanly from one site to a 10,000 device estate.
Authorise
Paste a NetBox API token into rConfig's Integrations screen. Scope the token to read only on the DCIM and IPAM apps in NetBox. Test Connection and Test Credentials buttons confirm reachability in seconds.
Scope
Filter the devices you want to bring across. Any combination of: site, tenant, device role, platform, manufacturer, tag, status, primary IP. Multiple filters combine with AND logic. Most teams start with a single site of ten to fifty devices.
Map
Translate NetBox roles, platforms, tags and custom fields into rConfig vendors, templates and credentials using tag based mapping. Set it up once, rConfig applies it on every sync thereafter.
Stage
Transformed devices land in rConfig's staging table for review. Idempotent: re-runs produce identical state, failures resume cleanly on the next cycle. Nothing goes to production without explicit promotion.
Sync
Run it now, schedule it (hourly, daily, weekly), or trigger it from the CLI with
php artisan rconfig:integration-netbox. Backup, diff and compliance run automatically from that point.
Built for how NetBox teams actually work.
The jobs the NOC, the security team and the auditor each need from network configuration management. No features bolted on for show.
Multi vendor configuration backup
Cisco, Juniper, Arista, Fortinet, Palo Alto, Huawei, Nokia, MikroTik, HPE, Aruba and 200 more. Hourly, daily or on demand.
Intent versus state drift detection
Compare running configuration against intended state derived from NetBox custom fields and config contexts. Surface drift as actionable findings through network assurance, not dashboard noise.
NIS2, DORA and CIS compliance reporting
Write policies once, run them against every NetBox managed device. Export evidence your auditor can actually read.
One click configuration restore
Push a known good configuration back to any device in under 90 seconds, with approvals and a full audit trail.
Bulk configuration deployment
Apply the same template across every NetBox filtered device in a single job with preview and rollback.
Full audit trail, exportable on demand
Who changed what, when, from where. The report your auditor asks for takes minutes, not days.
Deploys alongside NetBox. Consumes the API. Stays out of the database.
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.
From NetBox filter to compliance ready archive, in under a week.
A higher education institution in continental Europe runs NetBox across roughly 8,000 devices covering a multi campus network plus research labs and accommodation services. They adopted NetBox in 2021 as their IPAM plus DCIM, and spent two years trying to bolt config backup onto the same Nornir stack that drives their Ansible automation. By year three the stack was fragile enough that nobody wanted to touch it, and a looming audit made the problem unavoidable. They deployed rConfig, pointed the sync at NetBox filtered by device role (“core”, “distribution”, “access”, “security”), and had a full running config archive of all 8,000 devices inside five business days. The audit team signed off on the NIS2 evidence six weeks later without any engineer writing a line of Python.
That’s the difference between a source of truth that documents the network and a network you can actually prove to an auditor.
NIS2 and DORA evidence, anchored to the source of truth you already trust.
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.
rConfig compared to netbox-config-backup, Nornir plus NAPALM, and Netpicker.
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.
The NetBox integration, at a glance.
Everything your architecture review will ask about. Share this section with your security team before the demo.
- rConfig version
- 8.0 or later (V8 Pro, Enterprise or Vector)
- NetBox versions
- 3.x and 4.x, all minor and patch releases
- NetBox deployment types
- Self hosted open source NetBox, NetBox Cloud, NetBox Enterprise
- Authentication
- NetBox API token, scoped to read only on DCIM and IPAM apps
- Transport
- HTTPS
- Filterable fields
- Site, tenant, device role, platform, manufacturer, tag, status, primary IP
- Sync triggers
- Manual, scheduled, or CLI
- CLI command
php artisan rconfig:integration-netbox- Single device CLI
php artisan rconfig:integration-netbox-single-device {device_uuid}- Data flow
- One way, NetBox to rConfig (write back to custom fields on V8.4 roadmap)
- Idempotency
- Yes, re-runs produce identical state
- Logging
- Every sync logged with user, timestamp, device count, errors
- Plugin footprint in NetBox
- Zero (API only, no plugin required)
- High Availability
- Supported (point rConfig at the NetBox load balancer or HA endpoint)
- Documentation
- docs.rconfig.com/integrations/device-sync-overview
Questions NetBox users ask about network configuration management
Ten common questions from engineers evaluating the NetBox integration. If yours isn't here, ask it on the demo call.
Does NetBox do configuration backup natively?
No, and it's not supposed to. NetBox is a source of truth for intended state. Running config belongs in an external tool that consumes NetBox over the API. That's what rConfig does.
Does rConfig replace NetBox?
No. They solve different problems. NetBox is your source of truth. rConfig captures operational state, detects drift, and produces compliance evidence. Run both.
NetBox Cloud, NetBox Enterprise, or self hosted open source NetBox: which one works?
All three. Any NetBox deployment exposing the REST API over HTTPS is supported.
Do I need to install a plugin in NetBox?
No. rConfig integrates over the documented REST API using a read only token. Zero footprint in NetBox itself. Your NetBox admins can revoke rConfig's access at any time without touching the integration.
Can I sync a subset of my NetBox devices?
Yes. Filter by site, tenant, device role, platform, manufacturer, tag, status or primary IP. Multiple filters combine with AND logic. Most teams start with one site or one device role.
Does rConfig write back to NetBox?
Not in V8.2. The sync is one way, NetBox to rConfig. Write back to custom fields (populating last backup date and compliance status on the NetBox device record) is on the V8.4 roadmap.
How does rConfig handle NetBox platforms, roles and manufacturers?
They map to rConfig vendors, templates and credentials through tag based mapping. Define the mapping once, it's applied on every sync. rConfig's default mappings cover the common NetBox platform slugs out of the box.
How is this different from the netbox-config-backup plugin?
netbox-config-backup runs inside the NetBox process and stores backups in a Git repository. rConfig is a separate platform that consumes NetBox over the API and stores backups in its own archive with diff, compliance and restore capabilities. Different architecture, different operational model. For small estates with a Python comfortable team, the plugin is fine. For scale, compliance or operational simplicity, rConfig fits better.
How is this different from Netpicker?
Netpicker is a solid commercial alternative. rConfig predates them, has a larger installed base in regulated industries, ships with pre built NIS2 and DORA reporting templates, and includes bulk deployment and firmware management as first class features. Honest answer: evaluate both against your specific requirements.
How does rConfig handle large NetBox estates (10,000+ devices)?
The sync scales to estates of that size and beyond. Filter by site or role to stage rollout. Most large deployments run multiple sync configurations targeting different subsets of the estate, each on its own schedule.
See the sync running against your own NetBox inventory.
Book 30 minutes with an rConfig engineer. Bring the NetBox filters you already use. We'll mirror them, run the sync against a slice of your real inventory, back up a handful of your devices, and show you what drift detection looks like against your own intended state in NetBox. No generic demo. No slide deck. No sales gate.
Read the documentation
rConfig has supported NetBox integrations since 2023. Documented in our blog, documented in our docs, documented in production across dozens of customer networks.