RouterOS Configuration Management

The Core Problem: Config Changes Are Dangerous

Every network engineer has a story about a config change that went wrong. You add a firewall rule that accidentally blocks the management subnet. You modify a routing table entry and lose the return path to the device. You push an IP change to a remote router and realize, too late, that you just cut off your own access.

With RouterOS, these scenarios are especially common because changes take effect immediately. There's no staging area, no "apply and confirm" mechanism in WinBox or the CLI. The moment you hit enter, the change is live. If that change breaks your management path, you're locked out until someone physically accesses the device or you reach it through an out-of-band connection.

This is the fundamental problem that routeros configuration management needs to solve: making config changes safe, reversible, and auditable.

The Config Editor

The Other Dude provides a web-based config editor that exposes the full RouterOS path hierarchy — the same tree structure you navigate in WinBox. You browse /ip/address, /ip/firewall/filter, /interface, /routing/ospf, and every other RouterOS path from the web UI.

The config editor reads the current state of each path directly from the device via the RouterOS binary API. What you see in the editor is the live running configuration, not a cached snapshot. You can view entries, add new ones, modify existing ones, or remove them — the same operations WinBox provides, but through a browser.

The advantage over WinBox isn't the interface — WinBox is faster for single-device work. The advantage is everything that wraps around the edit: version history, audit logging, RBAC enforcement, safe-mode rollback when a change goes out as a restore or a template, and the ability to push the same change to multiple devices.

Safe Mode: The Safety Net

Which paths this covers. Config restore and template pushes are applied inside a RouterOS safe-mode session. If the device stops responding — for example because the change cut off the management path — the router reverts to its previous configuration on its own, without rebooting. Changes made in the config editor are applied directly and are not rolled back automatically. That distinction matters, so it is repeated wherever it is relevant on this page.

Safe mode is a RouterOS feature, not something layered on top of it. Entering it changes the device's own prompt to <SAFE> and makes the router track every configuration action taken in that session. Release the session cleanly and the changes stand. Lose it — for any reason — and the router undoes all of them itself.

A protected push runs like this:

1. Take an independent copy. A full binary /system backup is written to the device's own flash before anything changes, and the pre-push /export is already committed to git on the server.
2. Enter safe mode. The platform opens an SSH session to the device and enters safe mode, confirming it by the <SAFE> prompt rather than assuming it worked.
3. Apply inside the session. The config is uploaded over SFTP and applied with /import from within the safe-mode session, so every action it performs is in the undo buffer.
4. Verify on a new connection. After a 60-second settle, the platform dials a fresh, independent connection to the device. This is the part that actually proves anything: the existing session would keep answering even if the device had become unreachable to everything else.
5. Commit or let go. If the new connection succeeds, the session is released and the changes are kept. If it fails, the session is simply dropped and RouterOS reverts every change made in it.

The trigger for a revert is loss of the safe-mode session, not a timeout and not a confirmation you have to click in time. There is no confirmation window to miss. If the platform itself crashes, loses its network, or is killed halfway through a push, the device reverts for exactly the same reason it would if the change had broken connectivity.

And no reboot is involved. Safe mode unwinds the configuration in place. The device that reverts is the same device, still up, with the same uptime.

Pushes too large to protect are refused

RouterOS's safe-mode undo buffer holds 100 actions. Past that it does not warn, error, or log anything — it silently keeps the changes and carries on displaying the <SAFE> prompt, so there is no signal from the device that the safety net has stopped working. This was confirmed on hardware at 128, 140 and 150 actions.

The platform counts the change set before it opens the session and refuses any push that would exceed the limit. A too-large push fails cleanly and changes nothing on the device. That is the deliberate trade: a config push either has a working safety net or it does not happen.

Git-Backed Version History

Every config state is stored with full version history in PostgreSQL. When a config change is pushed through the platform, the before and after states are recorded along with a diff, the user who made the change, and a timestamp. When a change is detected from an out-of-band modification (someone used WinBox or SSH directly), the new state is captured on the next polling cycle.

The version history gives you:

• A complete timeline. Navigate through every configuration state the device has been in since it was added to the platform.
• Side-by-side diffs. Compare any two versions and see exactly what changed — additions, removals, and modifications highlighted line by line.
• Cross-device comparison. Compare the config of two different devices to identify configuration drift or verify consistency across a group.
• One-click restore. Select any previous version and push it back to the device, inside a safe-mode session so the router reverts itself if the restore breaks the management path.

This is functionally equivalent to having every config change committed to a git repository. You get the audit trail, the diff capability, and the ability to roll back — without requiring engineers to use git directly.

Simple Mode for Common Tasks

Not every config change requires navigating the full RouterOS path tree. The config editor includes a Simple Mode that provides a streamlined interface for the most common tasks: IP addressing, DHCP configuration, basic firewall rules, DNS settings, and interface management.

Simple Mode is modeled after consumer router interfaces — fill in the fields, click apply. Under the hood, it generates the same RouterOS commands and applies them the same way as the full config editor; only the UI complexity is reduced. That includes the safety behaviour: like the config editor, Simple Mode applies changes directly and does not run them inside a safe-mode session.

This is particularly useful for MSPs with operator-level staff who need to handle common tasks without deep RouterOS expertise. An operator can change a DHCP pool or add a port forward through Simple Mode without needing to know the exact RouterOS path syntax.

Template System

For fleet-wide configuration changes, the template system lets you define a set of RouterOS commands with variable placeholders. Variables are substituted per-device at push time, allowing a single template to be applied across devices with different IP ranges, interface names, or site-specific values.

Template pushes are safe-mode protected, per device: each device gets its own session, its own verification on a fresh connection, and reverts itself if that check fails. Rollouts run one device at a time, in order, and stop at the first device that fails rather than continuing into the rest of the group — so a bad template reaches one router, not fifty.

How This Differs from SSH Scripts and Ansible

The most common alternative to a config management platform is SSH scripting — either raw Bash/Python scripts or Ansible playbooks with the routeros modules. These approaches can work, but they require you to solve several problems yourself:

• No rollback. SSH scripts apply changes. If the change locks you out, you're locked out. There's no built-in safety net, and nothing took a copy of what was there before. Ansible's routeros modules don't drive safe mode either.
• No version history. Scripts produce the desired end state. They don't track what the config was before, what changed, or when. That's a separate system you'd need to build.
• No UI for browsing. Scripts push changes. They don't let you browse the current config tree, compare versions, or preview what will change before you apply it.
• Limited error context. SSH scripts give you exit codes and stderr. The platform gives you per-device success/failure with detailed error messages, rendered in a UI that shows the full batch result at a glance.
• No RBAC. Scripts run under whoever has the credentials. The platform enforces role-based access — viewers can't push, operators can push but can't manage users, admins have full control.

For teams with strong automation skills and simple requirements, scripts may be sufficient. For fleet-scale operations where safety, auditability, and access control matter, a purpose-built config management platform eliminates the infrastructure you'd otherwise need to build and maintain yourself.

Getting Started

The config editor is available immediately when a device is connected to the platform. The Quick Start guide covers deploying the platform and connecting your first device. Once connected, you can browse the device's config tree, make changes, and see the first backup appear in the version history. For changes you want safe-mode protection on, push them as a template or a restore rather than an editor edit.