Centralized Management for MikroTik Router Fleets

The Problem

Managing a handful of MikroTik routers is straightforward. You open WinBox, make your changes, and move on. But at some point — ten devices, fifty, a few hundred — that approach falls apart. Individual device management doesn't scale.

Without mikrotik centralized management, the same problems surface at every shop that runs RouterOS at any meaningful scale. Configuration inconsistencies accumulate across sites: one router is still running a deprecated DHCP pool, another has a firewall rule that was supposed to be temporary six months ago, a third has credentials that haven't rotated since a contractor left. Firmware versions drift across the fleet. Visibility disappears — you're not sure which devices are healthy until something breaks and a client calls.

The operational overhead compounds. Every change requires logging into each device individually. Rollbacks mean remembering what the previous state was, if you wrote it down at all. Audits are manual. Backups are either nonexistent or ad hoc shell scripts that may or may not have run recently.

The underlying issue is that device-by-device management doesn't give you a fleet. It gives you a collection of individual routers that happen to share a vendor. Centralized management is what turns that collection into something you can actually operate.

The Current MikroTik Management Landscape

The existing tools for routeros configuration management each cover part of the problem:

• WinBox — The standard MikroTik management tool, and genuinely excellent for what it does. Single-device configuration, real-time traffic monitoring, firewall rule editing — it's fast and purpose-built. But it's purely single-device. There's no fleet view, no bulk operations, no config history. It's the right tool for hands-on work on one router at a time.
• The Dude — MikroTik's own network management platform. Useful for L2/L3 topology discovery and basic device health at a glance. The monitoring features are decent for smaller deployments. However, configuration management is minimal, and the platform doesn't scale gracefully beyond a few hundred devices. It's a monitoring and topology tool, not a configuration management platform.
• SSH and API scripting — RouterOS scripting and the REST/JSON API are powerful, but they shift the burden onto you. You're writing your own error handling, your own state management, your own rollback logic. That's real engineering work. Scripts solve specific problems well but don't constitute a management platform.
• Third-party NMS platforms (PRTG, Zabbix, LibreNMS) — Strong on monitoring, weaker or nonexistent on configuration management. They'll tell you when a device is down or a threshold is breached, but they won't let you browse the RouterOS config tree, push changes safely, or manage credentials across the fleet.
• Commercial platforms (Unimus, NetBox, Auvik) — These solve real parts of the problem. Unimus in particular has solid RouterOS backup and config management. But commercial platforms are closed-source, cloud-dependent, or not purpose-built for MikroTik environments. For MSPs and ISPs who want full control over their data and deployment, they're a poor fit.

None of these options alone provides comprehensive mikrotik router fleet management across the full lifecycle: inventory, configuration, monitoring, backups, security, and operations in one place.

What Centralized Management Should Cover

A complete centralized management platform for MikroTik fleets needs to address six problem areas:

1. Visibility — A fleet-wide dashboard showing device inventory, health status, active alerts, bandwidth utilization, and wireless issues. You need to know the state of every device without logging into any of them.
2. Configuration — The ability to browse, edit, push, and track configuration changes across any device in the fleet. That includes safe push mechanisms with automatic rollback if a change breaks connectivity, template-based operations for applying consistent configs across groups of devices, and a change history that tells you what changed, when, and who made the change.
3. Monitoring — Real-time metrics with historical trending. Threshold-based alerts with configurable notification channels. The ability to suppress alerts during scheduled maintenance windows so on-call staff aren't paged for expected downtime.
4. Backups — Automated configuration snapshots that run without human intervention, a version timeline you can navigate, side-by-side diff views between any two snapshots, and a tested restore path. Backups that exist but can't be restored aren't backups.
5. Security — Encrypted credential storage, a complete audit trail of all management actions, role-based access control so operators can do their jobs without needing admin privileges, and tenant isolation for MSPs managing multiple clients.
6. Operations — Firmware version tracking and upgrade management, bulk command execution, VPN management, and maintenance workflow support.

How The Other Dude Provides Centralized MikroTik Management

The Other Dude is a self-hosted platform built specifically for MikroTik router fleet management. Here's what it covers across each area:

Fleet Visibility: The main dashboard surfaces device health, active alerts, bandwidth utilization, and wireless issues at a glance. The device table uses virtual scrolling to handle hundreds of devices without performance degradation. A geographic map and a network topology view (built on ReactFlow with Dagre layout) give you spatial and logical context for the fleet. A built-in subnet scanner handles device discovery when you're onboarding a new site.

Configuration Management: The config editor exposes the full RouterOS path hierarchy, letting you navigate and edit any config section the same way WinBox does — but with fleet-wide reach. Config pushes use a two-phase process: the change is applied, a connectivity check runs, and if the check fails the router automatically reverts to its previous state. This eliminates the risk of locking yourself out with a bad firewall rule or routing change. Simple Config mode provides a streamlined UI for common tasks — IP addressing, DHCP, firewall basics — modeled after consumer router interfaces for operators who don't need full RouterOS syntax exposure. Templates support variable substitution for batch operations across groups of devices.

Monitoring and Alerts: Health, traffic, and wireless metrics are stored in TimescaleDB hypertables, which handle high-frequency time-series data efficiently without requiring separate infrastructure. Alerts are threshold-based and configurable per device or device group. Real-time updates push via SSE backed by NATS JetStream. Maintenance windows suppress alerts for scheduled work so you're not managing noise during planned outages.

Security: Authentication uses SRP-6a — a zero-knowledge protocol where the server never sees your password. Device credentials are encrypted at rest using AES-256-GCM with per-tenant envelope encryption via OpenBao Transit. Role-based access control supports four roles (super_admin, admin, operator, viewer) with appropriate permission boundaries at each level. PostgreSQL Row-Level Security enforces tenant isolation at the database layer — one tenant's data is never accessible to another's, regardless of application-layer logic. Every management action is recorded in an immutable audit trail.

Self-Hosted: The entire platform deploys via Docker Compose. Your device credentials, configuration history, and monitoring data stay on your infrastructure. The platform is open source and available on GitHub.

Getting Started

Getting The Other Dude running against your first MikroTik device takes about ten minutes. Clone the repository, run setup.py to walk through the initial configuration, point the platform at your first router's IP, and you'll have a connected device with monitoring active and the first config backup in the timeline. Full setup instructions, including Docker Compose prerequisites and initial credential configuration, are in the Quick Start guide.