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: rollback protection, version history, audit logging, RBAC enforcement, and the ability to push the same change to multiple devices.

Two-Phase Commit: The Safety Net

This is the most important feature in the config management system. Every config push — whether from the editor, a template, or a bulk operation — uses a two-phase commit process:

1. Apply. The config change is sent to the device and takes effect immediately, as RouterOS requires.
2. Verify. The platform waits for a configurable confirmation period, continuously checking that the device is still reachable via the API.
3. Confirm or revert. If the device remains reachable throughout the confirmation period, the change is committed as permanent. If the device becomes unreachable at any point during the confirmation period — indicating the change broke the management path — the device automatically reverts to its pre-change configuration.

The revert mechanism uses RouterOS's built-in safe mode capabilities. The platform sets up a revert timer before applying the change. If the platform confirms the change successfully, it cancels the timer. If the platform loses contact with the device, the timer expires and RouterOS reverts the change on its own.

This means you can push a firewall rule to a remote router with confidence. If the rule blocks your management traffic, the router will revert itself. You don't need to call someone to reboot it. You don't need a serial console. The safety net is built into the push mechanism itself.

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, using the same two-phase commit mechanism for safety.

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 uses the same two-phase commit mechanism. The safety guarantees are identical; only the UI complexity is reduced.

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.

Templates combine with two-phase commit for safe bulk operations. Each device in the batch independently verifies the change and reverts if needed. A template push to 50 devices will succeed on the devices where the change works and revert on any where it doesn't.

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. Ansible's routeros modules don't implement two-phase commit.
• 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 and two-phase commit are 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 with rollback protection, and see the first backup appear in the version history.