What You Can Do With It Today (And What You Can't)

This is not a roadmap post. This is what the app actually does right now, today, in the code that's sitting on GitHub. If a feature isn't mentioned here, it either doesn't exist yet or it's too broken to talk about.

The Scenario

Say you're an MSP or a network engineer with forty MikroTik routers deployed across a dozen client sites. Some are hAP ac2s in offices, some are CCR1036s in racks, a couple of RB5009s doing weird things at edge locations. They're all on different firmware versions. Half of them have configs that drifted from what you intended months ago. You manage them by SSHing into each one individually, maybe with some scripts, maybe with The Dude if you're feeling nostalgic.

That's the situation this was built for.

What Actually Works

Fleet view. All your devices in one place. CPU, memory, disk, uptime, firmware version, connection status. The table handles hundreds of devices without choking — it uses virtual scrolling so you're not rendering a thousand DOM nodes. You can filter, sort, search. Basic stuff, but it works.

Device detail. Click into any device and you get real-time metrics — CPU load, memory usage, interface traffic with charts, wireless stats if it's an AP. These update live via server-sent events, not polling. You see what the router is doing right now, not what it was doing thirty seconds ago.

Command palette. Ctrl+K (or Cmd+K) opens a command palette. Type a device name, jump straight to it. Type a page name, go there. It's fast. You don't have to click through four menus to get where you're going.

Configuration management. This is the part that actually matters. You can view a device's running config, edit it, and push changes. Restores and template pushes go on inside a RouterOS safe-mode session, so if the change cuts off the management path the router undoes it by itself — no reboot, no timeout to miss, no confirmation to click. Editing directly in the config editor doesn't get that protection; those changes are applied straight to the device. Every config change is stored in git, so you get full history, diffs, and the ability to restore any previous version.

Config templates. Write a template once with variables, apply it across devices. Not a full-blown scripting language — just variable substitution for common patterns. Good enough for standardizing DNS settings across a fleet or rolling out a firewall rule change.

Bulk operations. Run a CLI command across multiple devices at once. Push a config to a batch of devices. Schedule a maintenance window so alerts don't fire while you're doing planned work. These all exist and function.

Config backups. Automatic, scheduled, git-backed. Runs every six hours by default. You can trigger one manually. You can restore from any point in history. This is the kind of thing that saves you at 2am.

Firmware tracking. The system checks MikroTik's servers daily for new firmware releases and shows you which devices are behind. It doesn't auto-update anything — that would be insane — but it tells you what's available and tracks your firmware audit state.

WinBox in the browser. You can launch a WinBox session to any device directly from the web UI. It runs in a container, tunneled through SSH. It's not fast on the initial load, and there are edge cases where sessions don't clean up properly. But it works. You don't need WinBox installed locally.

VPN overlay. For devices behind NAT, there's a built-in WireGuard overlay network. Devices connect out to your server, and you reach them through the tunnel. The app manages peer configs and routing automatically. This is how you poll and manage devices that don't have public IPs.

Multi-tenant. The system supports multiple tenants with full data isolation enforced at the database level via PostgreSQL row-level security. Each tenant sees only their own devices. This isn't bolted-on filtering — it's structural.

Authentication. SRP-6a zero-knowledge authentication. Your password never hits the server, not even as a hash. Per-tenant envelope encryption for stored credentials via OpenBao Transit. Emergency Kit export for account recovery. This part is built properly.

Alerts. You can set up alert rules on device metrics — CPU above threshold, device offline, interface down. Notifications go to email, webhooks, or Slack. Alert acknowledgment and silencing work.

Reports. PDF generation for fleet summaries, individual device reports, security audits, and performance overviews. Functional, not pretty.

Where It's Rough

WinBox sessions leak. A session that doesn't end cleanly — you close the tab, the browser dies, WinBox exits on its own — often isn't cleaned up. This paragraph used to call that "an orphaned container," which was wrong, and wrong in a way that made it sound smaller than it is. There is no per-session container. Every session is an Xpra + Xvfb + WinBox process tree running inside the one long-lived worker container, so a leaked session appears nowhere in docker ps and nothing sweeps it up.

It also isn't free. There are ten concurrent session slots. Leaks one through nine are invisible; the tenth means the next person to click WinBox gets a 503, and so does everyone after them. A leaked session additionally holds an authenticated connection open to the router it was pointed at. The ten-minute idle timeout that was supposed to catch abandoned sessions has never fired once — it looks for a field name in xpra info that this version of xpra doesn't emit — so at best an abandoned session sits there for the full two-hour lifetime cap, and a session the worker has lost track of doesn't age out at all. Fixing the session lifecycle properly is the current priority.

The map view is basic. Devices show up on a map if they have coordinates. That's about it. No topology overlays, no link visualization, no automatic geolocation. You have to manually set coordinates.

Network topology is early. There's a topology view that tries to discover device relationships. It works for simple networks. Complex MPLS or multi-VRF setups will confuse it.

Certificate management is new and lightly tested. There's an internal CA that can issue and deploy certificates to devices via SFTP. The three-tier TLS fallback logic is correct but hasn't been tested at scale.

The UI has rough edges. Some forms lack proper validation feedback. Some error messages are too technical. The mobile experience ranges from functional to annoying depending on the page. It's all usable, but you'll notice where it hasn't been polished yet.

Documentation trails the code. This is always true during active development, but it's especially true right now. Some docs describe things that changed last week. The code is the source of truth.

What's Missing Entirely

Updated August 30, 2026. This post was written in March and three of the five items below are no longer true — two shipped afterwards, one was wrong when it was written. Leaving them standing would be misleading rather than merely stale, so they're corrected inline rather than quietly deleted.

No traffic analytics page. Still true. The per-interface traffic page exists in the code and is routed, but it isn't in the sidebar, so you can only reach it by typing the URL. You can see interface counters in device detail in the meantime.

No wireless dashboard. Shipped — this one was just wrong. There is a Wireless entry in the sidebar. It lists the APs across the fleet that are actually in trouble, with signal in dBm, CCQ, and client counts, colour-coded by severity and refreshed every thirty seconds. There's a matching "APs Needing Attention" card on the overview page, and per-interface wireless charts on each device's detail page.

No high-availability deployment. Still true. The system runs as a single instance. If the server goes down, management goes down. The architecture supports horizontal scaling for the poller, but nobody has tested multi-replica deployments in production.

No automated firmware upgrades. Shipped. There is now a full upgrade path — download, upload, reboot, verify — for a single device or a staged mass rollout, with cancel, retry, and abort. The caution described here is now in the workflow rather than in the absence of the feature: nothing upgrades on a schedule, and every rollout is started deliberately.

No SNMP. Shipped. SNMP v1/v2c/v3 monitoring landed in v9.8, five days after this post went up, along with a custom profile builder and MIB upload. It is read-only — no SET, no traps — but non-MikroTik switches, APs, and UPSes now sit in the same fleet view as the routers.

Why It's Built This Way

A few things that are deliberate, not accidental:

Minimalism over features. Every feature that exists was added because a real workflow needed it, not because it looked good on a feature comparison chart. The goal is a small set of things that work reliably, not a large set of things that mostly work.

Safety over convenience. Restores and template pushes have automatic rollback, and a push too large for RouterOS to undo is refused rather than applied without a safety net. Credential encryption uses a real KMS, not a hardcoded key. Authentication doesn't send your password to the server. These choices make the system slightly more complex to set up but significantly harder to accidentally break.

Predictable behavior over magic. The system doesn't try to be clever. It doesn't auto-remediate. It doesn't silently retry failed operations. When something fails, it tells you it failed and lets you decide what to do. Magic is great until it does the wrong thing to production equipment at 3am.

No vendor lock-in. Self-hosted, and the source is published — though under the BSL 1.1, which is source-available rather than open source, and converts to Apache 2.0 in March 2030. Your data stays on your infrastructure. No cloud dependency, no phone-home, no license server. The optional telemetry is genuinely optional — disabled by default, anonymous when enabled, and you can see exactly what it collects.

What You Should Not Use It For Yet

If your business depends on a management platform being stable and predictable day to day, this isn't ready for that yet. The previous post was not kidding — this is not stable software. APIs change. Database schemas change. Features move around.

Don't deploy this as your only management tool for critical infrastructure. Run it alongside whatever you're using now. Use it for visibility and convenience, not as a single point of control. Treat it as a useful experiment, not a production dependency.

The Bottom Line

The app does real things today. You can manage devices, push configs safely, monitor fleet health, run WinBox from a browser, and maintain an audit trail of everything that happens. The security model is sound. The architecture handles scale.

It's also unfinished, sometimes rough, and will change without warning.

If that's useful to you now, use it. If not, check back later.

The Other Dude is source-available MikroTik fleet management — read the docs or view on GitHub.