Keep your network configuration in Git

By the end of this guide, every router, switch and firewall you run will have its configuration backed up to a private Git repository every night, with a readable history of what changed and when.

Who it's for

IT staff and network administrators with a handful to a few dozen network devices, comfortable with a command line and SSH. You'll need a private Git server or a private repository, a small Linux machine or VM to run a nightly job, and about an afternoon.

Why bother: without a saved configuration, replacing a failed firewall means rebuilding it from memory. Without a history, nobody can say what changed before the outage last Tuesday, or whether someone changed something they shouldn't have.

Steps

1. Create a private repository

   Use a self-hosted Git server such as Gitea, or a private repository with a hosted provider. Limit access to the network team. Plan one folder per site and one file per device, for example main-office/core-firewall.rsc.

2. Export each device's configuration, without secrets

   Every platform has a text export: /export on MikroTik RouterOS, show running-config on Cisco and similar switches, and a configuration backup file on pfSense, OPNsense and most firewalls. Configurations contain passwords, pre-shared keys and private keys, so export without them where you can (RouterOS 7, for example, hides sensitive values unless you ask for them) and check each file before the first commit. If you must keep secrets, encrypt those files, for example with age or git-crypt.

3. Commit a baseline

   Add all the exported files and commit them with a clear message, such as "Baseline configs, all sites". This is the known-good starting point you'll compare everything against.

4. Automate a nightly backup

   Create a read-only account with an SSH key on each device, used only for backups. Then schedule a nightly job that connects to each device, exports the configuration, and commits only if something changed. You can write a short script, or use a dedicated tool such as Oxidized, which already knows how to back up most network devices.

5. Make every change reviewable

   Before a planned change, make sure the latest configuration is committed. After the change, export again and commit with a message that says why, for example a ticket number. Then git diff shows exactly what changed, and anything that changed without a matching ticket stands out.

6. Practise a restore

   Take one configuration from the repository and load it onto a spare device or a virtual lab copy running the same firmware version. Note the steps, including how to put the secrets back, and keep them next to the configs. A backup you've never restored is only a hope.

Common mistakes

• Committing secrets. Wi-Fi keys, VPN keys and SNMP community strings in plain text turn your backup repository into a target. Strip or encrypt them, and if one slips in, change that secret: deleting it from Git isn't enough, because it stays in the history.
• A backup account with full admin rights. If the backup machine is compromised, so is every device. Read-only is enough to export.
• Never reading the diffs. An unexpected change overnight could be a mistake or an intruder. Have the job email a summary when something changes.
• Not recording firmware versions. A configuration may not load cleanly on a different firmware version. Commit the version alongside the config.
• Keeping the only copy on the same network. If the repository lives on a server in the same building, a fire or ransomware attack takes it with everything else. Mirror it offsite.