For nearly a decade, Oxidized (alongside its legacy predecessor RANCID) has been the undisputed champion of network configuration backups. It is lightweight, supports an impressive array of network operating systems, and is free.
For a single network engineer managing a single corporate LAN, Oxidized is fantastic.
But if you are a Managed Service Provider (MSP) managing dozens of client networks, hundreds of firewalls, and a rotating team of technicians, the open-source model starts to break down. Between maintenance overhead, security liabilities, and a lack of multi-tenancy, legacy network configuration managers (NCMs) are increasingly becoming an operational tax on MSPs.
Here is why it is time to move beyond Oxidized and how to modernize your network backups.
1. The Ruby Dependency Tax
Oxidized is written in Ruby. While Ruby is a powerful language, running it in production requires maintaining a gem ecosystem. Anyone who has run Oxidized for a few years has likely encountered the dreaded “Dependency Hell” during a system update.
- Gem Conflicts: A minor OS update breaks a Ruby gem dependency, causing the backup daemon to crash silently.
- Unsupported Drivers: If a new switch model is released, you must wait for the open-source community to write a driver or write custom Ruby code yourself to parse the device outputs.
- Maintenance Overhead: Your techs are network engineers, not Ruby developers. Every hour spent troubleshooting Docker container volumes, gem conflicts, or SQLite database corruptions is an hour not billed to a client.
Modern tools should run as self-contained, auto-updating binaries (or lightweight, pre-configured containers) that do not require language-level environment maintenance.
2. The Inbound Polling Security Risk
Traditional backup tools—including Oxidized, RANCID, and many commercial NCMs—use an inbound polling architecture. To back up a switch, the central backup server must reach out and initiate an SSH connection to the device.
For an MSP, this creates a major security dilemma:
- Exposing Ports to the WAN: To allow your central backup server to reach client switches, you must open SSH (port 22) or HTTPS (port 443) on the client’s WAN firewall, restricting it only to your server’s IP. If that restriction is ever misconfigured, or if an attacker spoofs the IP, your switch management plane is exposed.
- Complex VPN Meshes: Alternatively, you must set up and maintain a site-to-site VPN tunnel from your management network to every single client network. As you add clients, managing this VPN mesh becomes a routing and security nightmare.
The Modern Solution: Outbound-Only Agents
Modern network configuration management relies on local, outbound-only agents.
Instead of a central server reaching in, a lightweight agent is deployed inside the client’s local LAN (via a Docker container or a native Windows service). The agent connects locally to the switches and firewalls, redacts passwords in memory, encrypts the configuration, and pushes it outbound to the cloud portal over HTTPS.
No inbound ports. No WAN exposure. No VPNs.
3. The Management & Segmentation Challenge
Oxidized was never designed to manage multiple distinct client sites. It stores its inventory in flat files (like router.db) or simple SQL databases.
- Monolithic Configuration Files: In Oxidized, all devices are defined in a single, shared configuration file. As you scale to dozens of client sites, this file becomes unmanageable. A single syntax error or typo can take down the backup system for all of your clients simultaneously.
- Lack of Dashboard Segmentation: Oxidized doesn’t have native customer or site groupings in its UI. Switches from “Customer A” are pooled alongside firewalls from “Customer B” in a single list, making it difficult for your team to quickly find and compare devices for a specific client site.
- Local Agent Isolation: Managing backups across separate client LANs using a single monolithic server is highly error-prone.
A modern MSP backup tool needs built-in segmentation that allows you to organize devices by Customer and Site, using site-specific local agents to feed a unified dashboard.
4. The Documentation and PSA Gap
When a switch configuration drifts or a backup fails, an MSP needs to know immediately. In Oxidized, getting this information out of the tool requires writing custom webhooks, scripting Slack notifications, or manually checking git diffs.
Furthermore, it doesn’t integrate with the platforms MSPs use every day:
- IT Documentation (Hudu/IT Glue): Switch backups should automatically push updated configurations and diffs to your documentation assets so your team always sees current data.
- PSA/Ticketing (Syncro/ConnectWise): Backup failures should immediately open a ticket in your PSA, alerting the helpdesk before an outage happens.
Time to Modernize
Oxidized will always have a place in homelabs and internal IT departments that have the time to maintain it. But for professional MSPs, the risks of stale configs, WAN-exposed SSH ports, and manual script management are simply too high.
By moving to a modern, outbound-agent architecture like IronDiff, you get the lightweight CLI-native feel of Oxidized but with the security, dashboard customer segmentation, and native Hudu/Syncro integrations your MSP needs to scale.
Ready to automate your network backups securely? Get started with IronDiff for free.
