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. Config pushes use a two-phase commit with automatic panic revert — if the device doesn't confirm the change within a timeout, it rolls back. 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 occasionally hang. The container lifecycle management works most of the time, but sometimes a session doesn't terminate cleanly and you end up with an orphaned container. It's a known issue. It doesn't break anything else, it just wastes resources until it times out.
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
No traffic analytics page. The code for per-interface traffic visualization exists but isn't wired up yet. You can see interface counters in device detail, but there's no dedicated traffic analysis view.
No wireless dashboard. Same situation — the data is collected, the page is built, but it's not in the navigation yet.
No high-availability deployment. 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. The system tells you what's available. It doesn't push firmware. That's intentional for now — firmware upgrades on network equipment deserve more caution than a background job.
No SNMP. Everything talks RouterOS API. If you have non-MikroTik devices, this tool doesn't help you.
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. Config pushes have automatic rollback. 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. Open source. 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 open source MikroTik fleet management — read the docs or view on GitHub.