How to Manage Multiple MikroTik Routers from One Dashboard

The Problem

At five routers, WinBox tabs are manageable. You open a session per device, keep credentials in your head or a password manager, and move on. At fifty routers spread across multiple client sites, the tab approach breaks down: you're writing bash scripts to loop SSH connections, hoping your expect scripts handle timeouts gracefully, and maintaining a firmware spreadsheet that's perpetually out of date.

At two hundred routers or more, you're dealing with a different class of problem entirely. Pushing a firewall rule change means coordinating across dozens of simultaneous connections. A firmware upgrade cycle requires tracking which devices are on which RouterOS version, which hardware models support the target version, and which sites have maintenance windows. Onboarding a new client means manually provisioning credentials and confirming connectivity for every device they hand you. A single misconfiguration that bypasses your SSH loop silently fails and leaves one router out of compliance.

The operational cost compounds: credential sprawl, inconsistent configs across hardware generations, no audit trail for who changed what, and no alerting when a device goes offline at 3 AM except your phone at 3:05 AM.

Why MikroTik Lacks Fleet Management

MikroTik's tooling was designed for single-device administration. That's not a criticism — WinBox is genuinely good at what it does. But the design assumptions don't scale to fleet operations:

• WinBox is one device at a time. There's no concept of a device group, no bulk operation interface, no shared state between sessions.
• The Dude monitors but doesn't manage. It gives you network maps and SNMP polling, but it won't push a config change or track firmware versions across the fleet.
• No native cross-device API. The RouterOS API (port 8728/8729) is per-device. There's no management plane that aggregates across devices — you have to build that yourself.
• Each device is an island. There's no shared config state, no template system, no way to say "these 40 routers should all have this firewall ruleset."
• SSH scripting hits a ceiling. Scripts work until you need error handling, state tracking across partial failures, retry logic, and audit logging. At that point you're building infrastructure, not writing scripts.

The result is that most MikroTik fleet operators end up with a collection of tribal knowledge, SSH scripts of varying quality, and a Nagios instance that tells them about outages after the fact.

What MSPs and Network Teams Need

A workable mikrotik router fleet management solution needs to address several distinct operational concerns:

• Single-pane-of-glass visibility. Device count, online/offline status, uptime, CPU load, and memory usage across all routers without opening individual sessions.
• Batch configuration operations. Push a firewall rule or interface change to 50 devices simultaneously, with per-device success/failure reporting and rollback capability.
• Consistent firmware management. Know which devices are running which RouterOS version, which are behind, and which hardware supports the target version before you start an upgrade cycle.
• Credential management without spreadsheets. Store device credentials encrypted at rest, rotate them centrally, and audit access without maintaining parallel systems.
• Multi-tenant isolation. MSPs managing multiple client networks need hard boundaries between client data — not just UI filtering, but enforced at the data layer.
• Role-based access control. Junior staff doing monitoring shouldn't have the same permissions as senior engineers pushing config changes. Read-only, operator, and admin roles need to be enforced, not just honored.

How The Other Dude Manages MikroTik Fleets

The Other Dude was built specifically for this operational context. Here's what the platform provides:

Fleet dashboard. A single view shows device count, online/offline ratio, uptime sparklines, and per-device CPU and memory across your entire fleet. The device table is virtual-scrolled and handles hundreds of routers without performance degradation.

Batch configuration. Apply a config template to multiple devices simultaneously. Each device gets its own result — success, failure, or partial — and the operation is logged with a timestamp and the identity of who ran it. Config templates support variable substitution, so you can define a standard firewall ruleset once and apply it across sites with different IP ranges without editing the template for each device.

Bulk command execution. Run arbitrary RouterOS CLI commands across a device group. Useful for one-off queries (what's the uptime on all devices at site X?) or scripted changes that don't fit a template pattern.

Firmware tracking. The fleet view shows RouterOS version per device. You can filter to find devices below a target version and plan upgrade operations accordingly, accounting for hardware model compatibility.

Subnet scanner. Discover MikroTik devices on a given network segment. New devices show up in the scan results and can be added to the fleet directly.

Geographic map view. Devices can be assigned coordinates and viewed on a map, useful for ISPs and MSPs with geographically distributed deployments.

Multi-tenant support. Tenant data isolation is enforced at the PostgreSQL layer using Row-Level Security policies, not just filtered in the application. One tenant's devices, configs, and credentials are not accessible to another tenant regardless of application bugs.

RBAC. Four roles: super_admin, admin, operator, and viewer. Permissions are checked server-side on every request. Viewer accounts can monitor but cannot execute commands or push configs.

Credential encryption. All device credentials are encrypted at rest using AES-256-GCM. Keys are managed separately from the database.

Architecture Overview

For teams evaluating self-hosted options, the stack is straightforward:

• React frontend — web interface, virtual-scrolled device tables, real-time status updates via Server-Sent Events (SSE).
• FastAPI backend — REST API, authentication, RBAC enforcement, task orchestration.
• PostgreSQL + TimescaleDB — device inventory, time-series metrics, config history, multi-tenant RLS.
• Go poller — connects to devices using the RouterOS binary API over TLS (port 8729), collects metrics, executes commands, handles reconnection and error recovery per device.
• NATS JetStream — real-time event bus between poller and backend; device status changes and metric updates flow through here.
• Docker Compose — all components run as containers; a single compose file brings up the full stack.

There's no SaaS dependency, no phone-home requirement, and no cloud account needed. Everything runs on hardware you control.