Oxidized vs RANCID: Which Config Backup Tool Fits?

Oxidized and RANCID are open-source tools for backing up network device configs. Both log in to devices, collect text output, save versions, and help engineers see what changed.

The main difference is how they fit into daily work. Oxidized uses Ruby, supports more ways to load device data and save output, and offers an optional web interface and REST API. RANCID uses a long-established workflow built around Perl, Expect, router.db, version control, and email.

Oxidized vs RANCID: the quick answer

Choose Oxidized when you want a light config backup tool with Ruby models, Git-focused storage, flexible data sources, and an optional web interface and API.

Choose RANCID when you already have a stable setup, your team knows its scripts, and config collection with version control and email diffs meets your needs.

Choose a broader network configuration management platform when you also need managed user access, policy checks, reports, audit workflows, and guided recovery.

Oxidized vs RANCID feature comparison

Area	RANCID	Oxidized
Main job	Collect device configs and other device data, store revisions, and report changes.	Collect device configs, store revisions, and provide flexible ways to read and use the data.
Main language	Perl, with Expect used for device login.	Ruby.
Device list	Uses router.db and RANCID groups.	Can read CSV, SQLite, MySQL, or HTTP sources. Its CSV format can use a RANCID-compatible router.db.
Device access	SSH or Telnet through device login scripts.	SSH or Telnet through input modules.
Config storage	CVS, Subversion, or Git.	File, Git, Git-Crypt, or HTTP output.
Change history	Stored in the selected version-control system.	Usually stored in Git when the Git output is used.
Web interface	No built-in interface for configuring RANCID. External tools can display repository data.	An optional oxidized-web package provides a web interface.
API	No built-in REST API documented by the project.	The optional web package provides a REST API for nodes, configs, versions, diffs, and queue actions.
Change trigger	Normally runs on a schedule and can email diffs.	Runs on a retrieval schedule and can use syslog hooks to request a new fetch for supported workflows.
Device support	Supports Cisco, Juniper, Foundry and Brocade, HP ProCurve, and other device families.	The project states support for more than 130 operating-system types.
Extension model	Add or change Perl device modules and login scripts.	Add or change Ruby models, sources, outputs, inputs, and hooks.
Support	Project documentation and mailing lists.	GitHub, community chat, a LibreNMS forum, and project documentation.
Best fit	Teams that value a proven, file-based workflow and know the existing RANCID setup.	Teams that want a flexible, code-led backup service with Git and API options.

The table describes built-in project features. A skilled team can add other tools and controls around either system.

What Oxidized and RANCID have in common

Both tools solve the same first problem: get configs off network devices and keep a useful history.

They both:

• Run on infrastructure you control.
• Connect to many network device types.
• Collect text through device commands.
• Keep saved configurations outside the device.
• Let engineers compare versions.
• Can be changed and extended in code.
• Are open source.

Neither project is a full network monitoring platform. Their main job is device configuration collection and history.

How the Oxidized workflow works

Oxidized separates the device list, device model, connection method, and saved output.

A source tells Oxidized which devices to collect. Sources can include CSV, SQLite, MySQL, and HTTP. A model tells it which commands to run and how to clean the output. An output sends the saved config to a file, Git, Git-Crypt, or an HTTP service.

This split gives teams more ways to connect Oxidized to an existing toolchain. It also means the team must understand and maintain each chosen part.

For a fuller explanation, read what Oxidized is and how its config backups work.

How the RANCID workflow works

RANCID reads devices from router.db. Its login scripts connect to each device. Device modules run commands and filter values that may change on every collection. RANCID then saves the output in CVS, Subversion, or Git and can email a diff.

This workflow is simple and clear. It can also include local changes built up over many years. A team may have custom login rules, device modules, cron jobs, mail lists, and repository tools. Those parts matter when judging the real cost of keeping or replacing RANCID.

For a fuller explanation, read what RANCID is and how its config backups work.

Device support

Device support should be tested against your real estate. A vendor name alone is not enough. Check the device model, operating system, software version, login prompt, privilege flow, and commands you need.

Oxidized says it supports more than 130 operating-system types. Its models are written in Ruby. The model list includes major network vendors and can be extended when a device needs different commands or output filters.

RANCID supports Cisco, Juniper, Foundry and Brocade, HP ProCurve, and many other device types. Its modules are written in Perl.

Before choosing either tool, build a small test list that covers your oldest, newest, and least common devices.

Inventory and device sources

RANCID centres its inventory on router.db and groups. This is easy to read and works well for a file-based system.

Oxidized can also read a CSV file, including a RANCID-compatible router.db. It can instead load nodes from SQLite, MySQL, or an HTTP endpoint. That can help when another system already owns the device list.

This does not mean every RANCID setup moves to Oxidized with no work. Device type names, credentials, group rules, custom scripts, and stored history still need to be checked.

Version control and config history

RANCID can save revisions in CVS, Subversion, or Git. Its official documentation supports all three. It should not be described as a CVS-only tool.

Oxidized can save the latest file directly or create a Git commit when a config changes. Its project recommends the Git output. Git-Crypt can encrypt repository content, while the HTTP output can send data to another service.

For either tool, test more than the first backup. Confirm that a second collection creates the expected revision, that noisy values are filtered, and that an engineer can find the right older version during an incident.

Web interface and API

RANCID does not include a built-in web interface for configuring the system. A team can use external repository viewers for saved files and diffs.

Oxidized keeps its web interface and REST API in the optional oxidized-web package. The API can list nodes, fetch configs, show versions and diffs, reload the node list, and move a node to the front of the queue.

The Oxidized web package is useful for viewing and calling the backup service. It should not be confused with a full multi-user NCM application with built-in role, policy, reporting, and approval workflows.

Setup and day-to-day care

Oxidized suits engineers who prefer Ruby, YAML configuration, Git, and API-led links to other systems. It can run from packages or containers, depending on the chosen setup.

RANCID suits engineers who know Linux or Unix, Perl, Expect, version control, and scheduled jobs. Existing teams may already have years of working scripts and local knowledge.

Both need an owner. That person must manage the host, packages, device credentials, model changes, failed collections, storage, backups, and upgrades. Open-source software has no licence fee, but the team still owns the service around it.

Change alerts and faster collection

RANCID commonly runs on a schedule and emails a diff when a saved config changes.

Oxidized also collects on a set interval. Its documentation includes syslog hooks that can move supported IOS or Junos devices to the front of the queue after a change event. Other hooks can send or process diffs.

Neither method proves that every network change was approved. It shows that collected output changed. Teams that need approval, user records, or policy results should test those needs as separate controls.

Choose Oxidized when

• You are starting a new lightweight config backup service.
• Your team prefers Ruby models and YAML configuration.
• You want Git-focused storage.
• You want to load devices from a database or HTTP source.
• You want an optional web interface and REST API.
• You need flexible outputs and hooks.

Choose RANCID when

• Your current RANCID setup works well.
• Your team understands its Perl and Expect scripts.
• router.db, version control, and email diffs are enough.
• You want full control over a simple file-based workflow.
• You do not need an application interface or API.

When neither tool covers the full job

Oxidized and RANCID are good at config collection. Some teams later need a wider operating system for network configurations.

That wider job may include:

• User login and role-based access
• Managed schedules and device groups
• Search across configs and devices
• Policy and compliance checks
• Audit and operations reports
• Guided restore workflows
• Commercial support
• Scale across sites or customers

If those needs are part of your review, see the Oxidized alternative page, or compare rConfig as a RANCID alternative. You can also read the wider guide to open-source network configuration management tools.

Can you move from RANCID to Oxidized?

Oxidized can read a RANCID-compatible router.db through its CSV source. This can reduce work when moving the device list.

Plan the move as a test:

1. Copy a small set of devices into the Oxidized source.
2. Map each RANCID device type to the right Oxidized model.
3. Set and protect the required credentials.
4. Collect the first configs.
5. Compare the output with RANCID.
6. Test the second collection and diff.
7. Decide how to keep or archive the old revision history.
8. Run both tools until the new workflow is proven.

Custom RANCID scripts and old repository history do not become Oxidized models or Git history by themselves. Review them one by one.

Final choice

Oxidized is a sound choice for teams that want a flexible backup service with Git, multiple data sources, an optional web interface, and an API. RANCID is a sound choice for teams that value its established script and version-control workflow.

The best choice is the one your team can test, understand, and support. Start with real devices. Check the saved output. Test a failure. Find an old config. Make sure a second engineer can run the system.

Source note: This comparison was checked against the official RANCID documentation and the official Oxidized GitHub project on 13 September 2026. Features can change. Check each project before planning a production deployment.