rConfigPair PRTG with rConfig. Back up every device configuration. Prove compliance without writing custom sensors.
- SourcePRTG device tree
- rConfigDevice record
- Fans out to
- Backup archive
- Diff view
- Compliance report
rConfig reads your PRTG device tree over the REST API, backs up the running configuration of every monitored network device on the schedule you choose, diffs every change, and generates NIS2 or DORA evidence without custom sensors, without a PowerShell scheduled task, and without a second device inventory to maintain alongside the one PRTG already built for you.
PRTG Network Monitor, Enterprise Monitor and Hosted Monitor200+ vendor profilesSet up in under 30 minutes
PRTG knows every device on your network. It never backed up their configurations.
If you run PRTG, you already know why 500,000 sysadmins chose it. Auto discovery. Sensor based monitoring with 5 to 10 sensors per device. SNMP, WMI, NetFlow, jFlow, sFlow and a mature REST API. All in one installer, all in one licence, set up in minutes. Dirk Paessler was right in 1997: there is a simpler way to monitor a network, and PRTG is still one of the clearest expressions of that philosophy twenty five years later.
What PRTG was never built to do is pull the running config from the Cisco, Juniper, Arista or Fortinet devices it's monitoring. That's not a flaw. Configuration management is a separate discipline, and the PRTG product team has stayed focused on monitoring rather than blurring the scope.
That leaves a gap that shows up the moment an auditor asks what the ACL on the core switch looked like last March, or when a change gets pushed at 2am and nobody can work out what was there before. rConfig fills that gap. Vendor agnostic. 200+ device profiles out of the box. On prem, VM, bare metal or your private cloud. Your PRTG device tree becomes rConfig's device list over the REST API, and every configuration on every device lives in rConfig's versioned archive from that point forward.
- Running config isn't a PRTG sensor type. Never has been.
- Custom EXE or Script sensors calling TFTP or SNMP writes work until Windows Update changes something underneath them.
- PowerShell scheduled tasks pulling configs are the single point of failure nobody wants to inherit.
- Paessler partner integrations cover monitoring extensions beautifully. Configuration management lives outside that remit.
- Auditors don't care that your sensor stayed green. They care what the configuration looked like every Friday.
rConfig is the tool that picks up where PRTG's scope ends, and it does it without asking you to change a single thing about how you monitor.
PRTG plus rConfig, in three moves.
Sync, capture, prove. The three capabilities that turn a monitored PRTG estate into an audit ready one. Every device, every configuration, every change.
Sync
PRTG devices become rConfig devices automatically, scoped by PRTG group, device tag or custom property. Add a device to PRTG, it lands in rConfig on the next schedule. Retire one in PRTG, 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 custom sensors to maintain. No PowerShell scripts. No TFTP servers waiting to break.Prove
Compliance policies run against every PRTG monitored device. NIS2, DORA, PCI-DSS, CIS benchmarks and anything your security team writes. Evidence exports in minutes.
PRTG watches. rConfig remembers. Between the two, there’s no version of the network you can’t prove to an auditor.
How rConfig syncs with PRTG, step by step.
Four screens. Set up in under 30 minutes. Filter and mapping that scales cleanly from a five device pilot to a full estate.
- 01Step 1: AuthorisePaste a PRTG passhash or API token and server URL into rConfig's Integrations screen. The Test Connection and Test Credentials buttons confirm reachability in seconds.
- 02Step 2: ScopePick which PRTG devices to bring across. Filter by PRTG group, tag or custom property. Most teams start with a single test group of five to ten devices and widen from there.
- 03Step 3: MapTranslate PRTG tags, groups and device metadata into rConfig vendors, templates and credentials using tag based mapping. Set it up once, rConfig applies it on every sync thereafter. Default mappings cover the common PRTG device categories out of the box.
- 04Step 4: SyncRun it now, schedule it (hourly, daily, weekly), or trigger it from the CLI with
php artisan rconfig:integration-prtg. Idempotent: reruns produce identical state, failures resume cleanly on the next cycle.
The integration is one way by design. rConfig never writes to PRTG. Once devices are in rConfig, backup, diff and compliance run automatically. PRTG continues monitoring. Neither tool interferes with the other.
Built for how PRTG sysadmins 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.Change detection with a readable diff
See exactly what changed, line by line, since the last known good version. Filter out noise like timestamps and session identifiers.NIS2, DORA and CIS compliance reporting
Write policies once, run them against every PRTG monitored 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 PRTG device that matches a filter, 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 PRTG. Sets up in minutes. Stays out of the way.
rConfig does not install a PRTG sensor. Does not run on the Paessler PRTG server. Does not touch the PRTG database. All interaction happens over the documented PRTG REST API through a token or passhash that you scope yourself. That matters because it means rConfig cannot interfere with your PRTG performance, cannot consume PRTG sensor capacity, and cannot be the thing that breaks when you update PRTG.
What rConfig does is what PRTG was deliberately not built to do: capture 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. Supports PRTG Network Monitor, PRTG Enterprise Monitor and PRTG Hosted Monitor. Your sysadmin team is running it inside 30 minutes on V8 Pro or Vector.
Your monitoring.Your configuration.Your audit trail.
From PRTG sensor alert to restored configuration, in under fifteen minutes.
A mid market managed services provider in the Nordics runs PRTG across roughly 3,200 devices for 75 customer networks. Two sysadmins cover the full estate between them. At 22:14 on a Thursday, PRTG alerts on a bandwidth anomaly at a warehouse site for a logistics customer. The on call engineer pulls up PRTG and the sensor data shows a VLAN trunk dropping in and out. The diagnosis lives in rConfig: a VLAN change pushed by a contractor earlier that evening on the wrong interface. rConfig’s diff view surfaces the exact four line difference from the known good configuration, and the engineer rolls back with a single click. Service is restored at 22:29. The change management ticket is closed with the diff attached as evidence. No Python was written. No custom sensor was built. No second on call engineer was woken.
That’s what configuration management looks like when it’s built for sysadmins, not for scripting experts.
NIS2 and DORA evidence, sourced from the network PRTG is already watching.
If you’re in scope for NIS2 or DORA, regulators want two kinds of evidence. They want to know the network was available, and they want to know it was configured correctly. PRTG is the availability evidence. rConfig is the configuration evidence. Neither tool alone satisfies both halves of the audit.
Run both and your compliance process stops being a quarterly panic. Drift detection policies run automatically, every day, against every PRTG monitored device. When the auditor asks what the firewall ruleset looked like on 12 March, the evidence is already in rConfig’s archive. Your PRTG sensor history and rConfig configuration archive together cover availability and configuration for the same scope of devices.
rConfig compared to custom PRTG sensors, Oxidized or a home grown PowerShell script.
PRTG users who want configuration backup typically try one of three things before landing on a purpose built NCM platform. All three have their place.
Custom EXE or Script sensors pulling configs over TFTP, SNMP writes or SSH are the most common DIY approach. They work, they fit PRTG’s sensor model, and they are free. What they do not give you: a searchable archive, a readable diff, compliance reporting, RBAC, SAML SSO or audit ready evidence. And the first Windows Update that changes something about the underlying PowerShell execution breaks the sensor on a schedule you cannot predict.
Oxidized and RANCID are fine tools for shops with a dedicated automation engineer and a tolerance for Git and YAML debugging. Free. Works. Maintenance cost rises with the estate size.
rConfig’s positioning is simple. If you have Python and Git capacity in house and a small enough estate that maintenance is manageable, DIY is a reasonable choice. If you need compliance evidence your auditor can read without a walk through, RBAC and SAML out of the box, commercial support with SLAs, and a platform your sysadmin team can operate without becoming scripting experts, rConfig is the tool that gets you there faster. Most teams move to rConfig after their DIY sensor or script breaks at the wrong moment and the engineer who wrote it has moved on.
The PRTG 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)
- PRTG versions supported
- PRTG Network Monitor 22.x and later, PRTG Enterprise Monitor, PRTG Hosted Monitor
- Authentication
- PRTG API token or username plus passhash
- Transport
- HTTPS, with optional support for internally signed certificates
- Filterable fields
- PRTG group, tag, custom property, device category
- Sync triggers
- Manual, scheduled, or CLI
- CLI command
php artisan rconfig:integration-prtg- Single device CLI
php artisan rconfig:integration-prtg-single-device {device_id}- Data flow
- One way, PRTG to rConfig
- Idempotency
- Yes, reruns produce identical state
- Logging
- Every sync logged with user, timestamp, device count, errors
- PRTG footprint
- Zero custom sensors, zero PRTG server impact
- High Availability
- Supported (point rConfig at the PRTG master probe or load balancer)
- Documentation
- docs.rconfig.com/integrations/device-sync-overview
Questions PRTG sysadmins ask about network configuration management
See the sync running against your own PRTG inventory.
Book 30 minutes with an rConfig engineer. We’ll point the integration at a slice of your real PRTG device tree, back up a handful of your actual devices, and run a compliance report against a policy that matters to your team. No generic demo. No slide deck. No sales gate.
Set up in under 30 minutes. Backs up from day one. No PRTG custom sensor required.