rConfigPair Nautobot with rConfig. Back up operational reality. Prove compliance without writing Jinja.
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.xTag-driven syncRuns alongside Golden Config, or instead of it
Nautobot models intended state. It does not capture what the network actually looks like.
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.
- Golden Config assumes Python-capable operators. Not every Nautobot deployment has them.
- Jinja template authoring for intended config takes weeks even when the skill is in-house.
- GraphQL queries for compliance logic require fluency the NOC typically does not carry.
- When the engineer who built the pipeline moves on, the pipeline usually moves on with them.
- Most auditors want NIS2 or DORA reports today, not after a six-month NetDevOps enablement programme.
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.
Nautobot plus rConfig, in three moves.
Ingest, capture, reconcile. Data-driven, tag-scoped, and wired to the auditor-ready outputs your team actually needs to ship.
Ingest
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.Capture
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.Reconcile
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.
Nautobot holds intended state. rConfig captures operational reality. Between the two, there is no version of the network you cannot prove.
How rConfig consumes Nautobot, step by step
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.
- 01Step 1: AuthorisePaste a Nautobot API token into rConfig's Integrations screen. Scope the token to read permissions on the relevant DCIM and IPAM objects. Test Connection and Test Credentials buttons confirm reachability in seconds.
- 02Step 2: ScopeFilter 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.
- 03Step 3: MapTranslate 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.
- 04Step 4: StageExtracted 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.
- 05Step 5: SyncRun it now, schedule it, or trigger it from the CLI with
php artisan rconfig:integration-nautobot. For single-device sync and debugging, usephp artisan rconfig:integration-nautobot-single-device {device_uuid}. Backup, diff and compliance run automatically from that point.
The integration is one-way by design. rConfig never writes to Nautobot. If inventory drifts between the two systems, Nautobot remains the source of truth and rConfig reconciles on the next sync. Write-back to Nautobot custom fields (populating last-backup-date and compliance-status on the device record) is on the V8.4 roadmap.
Built for how Nautobot 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-reality drift detection
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.NIS2, DORA and CIS compliance reporting
Write policies once, run them against every Nautobot-managed device. Export evidence your auditor can actually read, without writing a Python report generator.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 Nautobot-tagged 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.
Golden Config, rConfig, or both: how to choose honestly.
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.
Golden Config is the right answer when:
- You have at least one full-time Python-capable network automation engineer.
- A NetDevOps operating model is already in place or actively being adopted.
- Your team is comfortable owning Jinja templates, Nornir jobs, and GraphQL queries.
- Your compliance scope is narrow and well-understood.
- You want the tooling to live inside the Nautobot process itself, as a native app.
rConfig is the right answer when:
- Your team is network-operations-led rather than software-engineering-led.
- You need commercial support with real SLAs.
- You need compliance reporting an auditor can read without a walk-through.
- You need RBAC, SAML SSO, and approval workflows on day one rather than built into custom jobs.
- You want to be in production in weeks, not quarters.
- You already have Golden Config running somewhere but need faster time-to-value elsewhere in the estate.
Plenty of organisations run both. Golden Config on the NetDevOps-heavy sites where the team has the skill and capacity to own it, rConfig on the rest of the estate where the priority is delivering compliance evidence without building a Python practice first. The two tools do not conflict. They consume Nautobot through different access paths and produce outputs with different audiences in mind.
Deploys alongside Nautobot. Consumes the API. Does not compete with Golden Config.
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.
Your source of truth.Your operational reality.Your audit trail.
From Nautobot inventory to compliance-ready archive, in under two weeks.
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.
NIS2 and DORA evidence, anchored to Nautobot’s intended state.
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.
The Nautobot 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)
- Nautobot versions
- 2.x LTM and all 3.x releases
- Nautobot deployment types
- Self-hosted open-source Nautobot, Nautobot Professional, Nautobot Enterprise, Nautobot Cloud
- Authentication
- Nautobot API token
- Transport
- HTTPS, optional support for internally-signed certificates
- Filter model
- Nautobot tags, combined with AND at the API level. Use multiple sync configurations for OR logic.
- Sync triggers
- Manual, scheduled, or CLI
- CLI command
php artisan rconfig:integration-nautobot- Single-device CLI
php artisan rconfig:integration-nautobot-single-device {device_uuid}- Data flow
- One-way, Nautobot to rConfig (write-back on V8.4 roadmap)
- Idempotency
- Yes, re-runs produce identical state
- Logging
- Every sync logged with user, timestamp, device count, errors
- App footprint in Nautobot
- Zero (API-only, no Nautobot app required)
- Compatibility with Golden Config
- Yes, both can run against the same Nautobot deployment without conflict
- Compatibility with Nautobot SSoT
- Yes, rConfig consumes Nautobot downstream of whatever SSoT sources populate it
- High Availability
- Supported (point rConfig at the Nautobot load balancer or HA endpoint)
- Documentation
- docs.rconfig.com/integrations/device-sync-overview
Questions Nautobot users ask about network configuration management
See the sync running against your own Nautobot inventory.
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.
Honest answers about where rConfig fits and where it doesn’t. If Golden Config is right for you, we’ll tell you.