Short answer: Open-source network configuration management tools do not all work in the same way. RANCID is a script-based config collector. Oxidized is a light and flexible collector. rConfig Core is a self-hosted app with a web interface and API. The right choice depends on the work your team wants to manage.
This guide compares the three approaches. It looks at config collection, history, user access, APIs, and daily use. It does not rank tools by age. It helps you choose a tool that fits your network and your team.
What is an open-source NCM tool?
NCM means network configuration management. At a basic level, an NCM tool connects to a network device, gets its config, and saves a copy. It should also help you see what changed.
Some open-source NCM tools stop there. Others add a web app, an API, user access, reports, and ways to run jobs. This difference matters. A good config collector may not be a full management app. A full app may need more server resources and care.
If you need a wider introduction before comparing products, read our guide to network configuration management.
Open-source NCM tools at a glance
| Area | RANCID | Oxidized | rConfig Core |
|---|---|---|---|
| Main form | Script-based collector | Modular collector | Self-hosted web app |
| Main job | Collect configs and save changes | Collect configs and send them to an output | Back up, find, and compare configs |
| History | CVS, Subversion, or Git | File, Git, Git-Crypt, or HTTP output | Managed version history |
| Interface | Command line; no built-in setup GUI | Command line; optional web interface | Built-in web interface |
| API | No built-in REST API in the main project | REST API through the optional web package | Built-in REST API |
| Good fit | Teams that want a known script and version-control flow | Teams that want a small, flexible collector | Teams that want an app, UI, API, and config history |
This table shows the main product shape. It does not show every device model or plug-in. Check support for your own devices before you choose.
RANCID: a script and version-control workflow
RANCID gets config and hardware data from network devices. It can keep the results in CVS, Subversion, or Git. It can use SSH or Telnet, based on the device and setup.
RANCID has no built-in GUI for setup. Your team works with text files, scripts, groups, jobs, email, and a version-control system. This can be a good fit when that flow is already known and well run.
Before you deploy it, test your device types and login flow. You should also plan who will care for the host, scripts, secrets, jobs, and repository.
Read how RANCID config backups work for a focused guide to its parts and daily care.
Oxidized: a small and flexible collector
Oxidized is written in Ruby. It separates the device list, device model, input, and output. This makes it easy to shape the collection flow around other systems.
It can read device data from sources such as CSV, SQLite, MySQL, or HTTP. It can write config data to a file, Git, Git-Crypt, or an HTTP service. Its optional web package adds a web view and REST API.
Oxidized is a good fit when your team wants a focused collector and can build the rest of the operating flow around it. You still need to decide how users log in, where data is stored, how secrets are kept, and how failures are found.
If these are the two tools on your shortlist, read the full RANCID vs Oxidized comparison. That page owns the direct head-to-head question.
rConfig Core: an open-source NCM app
rConfig Core is free, open-source, and self-hosted. It puts device jobs, config history, and search in a web app. It also has a REST API.
Core can run on your own server, in your own cloud, or in an offline site. It has no licence fee or set device cap. Your real limit will depend on the server, device mix, job rate, and network links.
Core is a good fit when more than one person needs a clear app for config backups and history. It can also suit teams that want to connect NCM work to their own scripts through an API.
Commercial rConfig editions add more features and support. Check the current product page before you map a feature to an edition.
These tools do not cover every network task
A config collector is not the same as a network monitor. It may not draw maps, test link health, or alert on traffic. It is also not the same as an automation library, source-of-truth database, or config test engine.
Your stack may use more than one tool:
- An NCM tool to get and keep device configs.
- A monitor to watch device and link health.
- An inventory system to hold device facts.
- An automation tool to make approved changes.
- A test tool to check a planned or saved config.
Write down which system owns each job. This stops gaps and duplicate work.
How to compare open-source NCM tools
1. Check your devices
Make a list of vendors, models, and software versions. Test real devices. A long support list is useful, but a clean backup from your own device is better proof.
2. Check how the tool connects
Look at SSH, Telnet, API, and other input methods. Use the safest method your device can support. Check how the tool deals with prompts, timeouts, and slow links.
3. Check config history
Run two backups. Change one safe line. Run another backup. Make sure the tool keeps both copies and shows the right change.
4. Check secrets and user access
Find out where device passwords and keys live. Check who can see them. If the tool has a web app, test user access and session controls. If it does not, check the host and repository controls.
5. Check the API and integrations
Do not choose an API from a feature list alone. Test the action you need. This may be adding a device, starting a job, getting a config, or reading job status.
6. Check failure handling
Break one test login. Stop one test device. Make sure the failed job is easy to find. Decide who gets the alert and who fixes it.
7. Check recovery
A saved file is only useful if your team can use it. Find an older config. Export it. Check it. Then follow your approved recovery steps on a lab device.
8. Count the full cost
Open source can remove a licence fee. It does not remove the work. Count server time, updates, backups, monitoring, custom code, training, and support.
A simple test plan
Use the same test for each tool. This gives you a fair result.
- Pick 10 devices that reflect your real network.
- Install the tool on a clean test server.
- Add the devices and run the first backup.
- Make one approved test change.
- Run the next backup and find the diff.
- Export an older config for recovery.
- Break one login and check the error flow.
- Ask a second engineer to find the same data.
- Record setup time and weekly care.
The best tool is the one your team can run well. A small tool with a clear owner may beat a large app that no one maintains. A web app may beat scripts when many people need safe and simple access.
Which approach fits your team?
- Choose RANCID when you want an established script-based flow and your team is happy to manage the host, files, jobs, and version control.
- Choose Oxidized when you want a light collector with flexible sources, outputs, and an optional API.
- Choose rConfig Core when you want a self-hosted app with a built-in UI, API, and config history.
If you already use RANCID and want to change systems, see the RANCID migration guide. It covers the move without turning this category guide into a replacement page.
Start with a real device test
Do not start with a long feature list. Start with your devices and your daily jobs. Test backup, diff, failure, access, and recovery.
Want to try the app-based approach? Download rConfig Core. You can run it on your own server and test it with a small device group first.
Product details checked on 13 September 2026. Open-source projects and product editions can change. Check the linked project and product pages before you deploy.
