rConfig consumes your Nautobot inventory over the REST API, backs up the running configuration of every device on your schedule, detects drift between Nautobot’s intended state and the network’s operational reality, and generates NIS2 or DORA evidence without a Python pipeline to own, without a Jinja template library to author, and without hiring a NetDevOps engineer you do not have.
Nautobot 2.x and 3.x. Tag driven sync. Runs alongside Golden Config, or instead of it.
If you run Nautobot, you already know the distinction the Network to Code team hammers at every conference: a source of truth holds intended state, the network itself is your source of reality, and automation only works when the two are in sync. Nautobot handles the first half of that loop beautifully. It models devices, IPs, circuits, custom relationships, config contexts, and increasingly sophisticated validation rules in Nautobot 3.0.
What Nautobot does not do on its own is capture what’s actually running on those devices right now. That’s where Golden Config typically enters the picture, and for NetDevOps led teams with Python and Jinja capacity on the bench, Golden Config is a fine answer. It’s built by Network to Code, it’s Apache 2, it’s actively maintained, and it fits the Nautobot automation model cleanly.
Golden Config is not the right answer for every team running Nautobot. Plenty of teams inherited Nautobot from a previous engineer, a consultancy engagement or a different operating model. They need configuration backup, drift detection and compliance evidence now, and they do not have the capacity to hire a NetDevOps engineer and build out a Nornir plus Jinja plus GraphQL stack first. That is the problem rConfig solves.
If Golden Config is the right tool for your team, run it. If it is not, rConfig is the other tool that consumes Nautobot cleanly and delivers the same outcomes without the Python dependency.
Ingest, capture, reconcile. Data driven, tag scoped, and wired to the auditor ready outputs your team actually needs to ship.
Nautobot devices become rConfig devices automatically, scoped by Nautobot tag, location, role, platform or status. Add a device in Nautobot, it lands in rConfig on the next schedule. Retire one in Nautobot, it's flagged in rConfig for review before anything breaks.
Every running config, every startup config, every change, stored and diffable. 200+ vendors out of the box. No Nornir jobs to write. No Jinja templates to maintain. No GraphQL queries to debug at 2am.
Compliance policies run against every Nautobot managed device. NIS2, DORA, PCI-DSS, CIS benchmarks and anything your security team writes. Compare operational reality against Nautobot's intended state for drift detection. Evidence exports in minutes.
Five screens. Ten minutes for a tag scoped pilot. Nautobot tag driven filtering that scales cleanly from one role to a 10,000 device estate.
Paste a Nautobot API token into rConfig's Integrations screen. Scope the token to read permissions on the relevant DCIM and IPAM objects. The Test Connection and Test Credentials buttons confirm reachability in seconds.
Filter the devices you want to bring across using Nautobot tags. The Nautobot API combines multiple tag filters with AND logic. If you need OR logic (for example, all “core” devices or all “security” devices), create multiple sync configurations in rConfig, each scoped to a single tag. Most teams start with one tag covering ten to fifty test devices.
Translate Nautobot platforms, roles and tags into rConfig vendors, templates and credentials using rConfig's tag based mapping. Set it up once, rConfig applies it on every sync thereafter. Default mappings cover the common Nautobot platform slugs out of the box.
Extracted devices land in rConfig's staging table for review. The sync is idempotent: re-runs produce identical state, failures resume cleanly on the next cycle. Nothing goes to production without explicit promotion.
Run it now, schedule it, or trigger it from the CLI with php artisan rconfig:integration-nautobot. For single device sync and debugging, use php artisan rconfig:integration-nautobot-single-device {device_uuid}. Backup, diff and compliance run automatically from that point.
The jobs the NOC, the security team and the auditor each need from network configuration management. No features bolted on for show.
Cisco, Juniper, Arista, Fortinet, Palo Alto, Huawei, Nokia, MikroTik, HPE, Aruba and 200 more. Hourly, daily or on demand.
Compare running configuration against intended state derived from Nautobot custom fields, config contexts and relationships. Surface drift as actionable findings through network assurance, not dashboard noise.
Write policies once, run them against every Nautobot managed device. Export evidence your auditor can actually read, without writing a Python report generator.
Push a known good configuration back to any device in under 90 seconds, with approvals and a full audit trail.
Apply the same template across every Nautobot tagged device in a single job with preview and rollback.
Who changed what, when, from where. The report your auditor asks for takes minutes, not days.
Most teams running Nautobot will, at some point, need to make this decision. We get asked about it often enough that it deserves its own section rather than being buried in an FAQ.
rConfig does not install a Nautobot app. It does not run inside the Nautobot process. It does not touch the Nautobot database directly. All of its interaction with Nautobot happens over the documented REST API, through a read only token that you scope yourself. Golden Config can be running in the same Nautobot deployment and neither tool will notice the other. They read the same source of truth and do not collide.
What rConfig does is what Nautobot’s core was deliberately not built to do: 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 Nautobot 2.x LTM and all 3.x releases. Your ops team is running it inside 30 minutes on V8 Pro or Vector. If you’re evaluating between Nautobot and NetBox as your source of truth, rConfig consumes either one the same way. Many teams also run Zabbix for monitoring in the same stack.
A national utility in Northern Europe runs Nautobot across roughly 4,500 devices covering substations, corporate IT, SCADA and a small number of customer facing service points. Nautobot was deployed in late 2023 as part of a broader modernisation programme, and the team spent most of 2024 building out config contexts, custom relationships and a small Golden Config footprint for the SCADA subset. When NIS2 enforcement dates moved forward in 2025, the team needed compliance evidence across all 4,500 devices, not just the SCADA subset, and they did not have the NetDevOps capacity to extend Golden Config across the whole estate in the time available. They deployed rConfig, pointed the sync at Nautobot filtered by three tags (“compliance-scope-nis2”, “compliance-scope-pci”, “compliance-scope-general”), and had drift detection reports running against their full Nautobot inventory inside nine business days. Golden Config continues to serve the SCADA subset where it was already working. rConfig covers the rest.
That’s not Golden Config versus rConfig. That’s Golden Config plus rConfig, each doing the job it’s best at.
If you’re in scope for NIS2 or DORA, the regulators want two kinds 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. Nautobot handles the second half natively (that is what a source of truth is for). rConfig handles the first half and reconciles both sides.
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 Nautobot 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 Nautobot’s intended state record for that device at that point in time.
Everything your architecture review will ask about. Share this section with your security team before the demo.
php artisan rconfig:integration-nautobotphp artisan rconfig:integration-nautobot-single-device {device_uuid}Ten common questions from engineers evaluating the Nautobot integration. If yours isn't here, ask it on the demo call.
Not necessarily. Golden Config is a fine tool for NetDevOps led teams with Python and Jinja capacity on the bench. rConfig is the right answer for teams that do not have that capacity or do not want to build it just to deliver compliance evidence. Many customers run both, with each tool covering the subset of the estate it's best suited for.
Yes. They consume Nautobot through different access paths and do not conflict. Define non overlapping device scopes so each tool owns a clean subset of the estate.
No. Nautobot remains your source of truth for intended state. rConfig captures operational reality, detects drift, and produces compliance evidence. Different jobs, different tools.
Nautobot 2.x LTM and every 3.x release. Nautobot 3.0 shipped in December 2025 with native Approval Workflows, Load Balancer and VPN data models, and a refreshed UI, all of which rConfig supports.
The Nautobot API combines multiple tag filters with AND logic. If you need OR logic (for example, all devices tagged "core" or "distribution"), create multiple sync configurations in rConfig, each scoped to a single tag. Each configuration runs on its own schedule and feeds the same rConfig device table.
No. rConfig integrates over the documented REST API using a read only token. Zero footprint in Nautobot itself. Your Nautobot admins can revoke rConfig's access at any time without touching the integration.
Not in V8.2. The sync is one way, Nautobot to rConfig. Write back to custom fields (populating last backup date and compliance status on the Nautobot device record) is on the V8.4 roadmap.
Yes. Nautobot SSoT synchronises data between Nautobot and upstream systems like ServiceNow, Infoblox and Device42. rConfig consumes Nautobot downstream of whatever SSoT sources populate it, so the two layers complement each other without overlap.
Device Onboarding pulls configuration data from devices into Nautobot to help build out intended state. rConfig does the opposite: consumes intended state from Nautobot and backs up operational reality from the devices. The two tools face opposite directions in the automation loop.
The sync scales to estates of that size and beyond. Use Nautobot tags to stage rollout. Most large deployments run multiple sync configurations targeting different subsets of the estate, each on its own schedule.
Book 30 minutes with an rConfig engineer. Bring the Nautobot tags 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 Nautobot. If you already run Golden Config, we'll show you exactly where rConfig fits alongside it rather than trying to talk you out of what's already working. No generic demo. No slide deck. No sales gate.
Read the documentation
Honest answers about where rConfig fits and where it doesn’t. If Golden Config is right for you, we’ll tell you.