MikroTik Management for MSPs

The MSP Problem

Managed service providers running MikroTik networks face a specific set of challenges that single-organization deployments don't. The fundamental issue is multi-tenancy: you manage devices for multiple clients from the same team, the same tools, and ideally the same platform. But Client A's device credentials, configuration data, and monitoring history must be completely invisible to Client B. This isn't a nice-to-have — it's a contractual and often regulatory requirement.

Most MikroTik management approaches don't account for this. WinBox sessions are per-device with no concept of client boundaries. SSH scripts run under a single operator's credentials with no built-in tenant separation. Even purpose-built network management platforms often implement multi-tenancy as UI-level filtering rather than enforced data isolation — which means a bug, a misconfigured query, or an API endpoint that forgets to filter can expose one client's data to another.

Beyond isolation, MSPs need operational structure: who on your team can see what, who can push config changes vs. just monitor, and who did what when a client asks about a change they didn't authorize.

Tenant Isolation at the Database Level

The Other Dude implements multi-tenant isolation using PostgreSQL Row-Level Security (RLS). Every table that stores tenant-scoped data — devices, configurations, metrics, credentials, audit logs — has RLS policies that filter rows based on the authenticated user's tenant ID. This enforcement happens at the database layer, not in application code.

What this means in practice: even if there's a bug in the API that fails to include a tenant filter in a query, PostgreSQL itself will refuse to return rows belonging to a different tenant. The isolation boundary is the database engine, not the application logic sitting on top of it.

Each tenant's data is a completely separate partition. There is no shared device table where rows are tagged with a tenant ID and filtered at query time. The RLS policies ensure that a query executed in the context of Tenant A literally cannot see Tenant B's rows, regardless of what the application does.

Per-Tenant Encryption

Device credentials — the SSH and API passwords your team uses to connect to client routers — are encrypted at rest using AES-256-GCM with per-tenant envelope encryption. The encryption keys are managed by OpenBao Transit (a community fork of HashiCorp Vault). Each tenant has its own encryption key. Compromising one tenant's key does not expose another tenant's credentials.

This matters because device credentials are the most sensitive data in any network management platform. A single leaked credential set can provide direct access to a client's router infrastructure. Per-tenant envelope encryption ensures that even in a worst-case scenario — database breach, backup theft — the credentials are encrypted with keys that aren't stored alongside the data.

RBAC: Who Can Do What

The platform enforces four roles with server-side permission checks on every request:

• super_admin — Platform-level administration. Can create and manage tenants, manage users across the platform, and access system-level settings. Cannot see individual tenant device data — this is a privacy boundary, not a convenience feature.
• admin — Tenant-level administration. Can add/remove devices, manage users within their tenant, configure alert rules, push configuration changes, and manage backups. Full operational control within their tenant scope.
• operator — Day-to-day operations. Can view devices, run CLI commands, execute bulk operations, and manage configs. Cannot add/remove devices or manage users. This is the role for NOC engineers who need to operate the network but shouldn't be changing the fleet inventory.
• viewer — Read-only access. Can view dashboards, monitoring data, device status, and config history. Cannot execute any commands or push any changes. Useful for client contacts who want visibility into their own network without operational access.

Roles are checked server-side on every API request. The frontend hides UI elements based on role, but the actual enforcement is in the backend — a viewer who crafts a manual API request to push a config change will get a 403, not just a hidden button.

Audit Trail

Every management action is recorded in an immutable audit log: config pushes, command executions, device additions, user management changes, credential access, WinBox session launches. Each entry includes the user, timestamp, tenant, action type, and relevant details.

For MSPs, this serves two purposes. First, it's your operational record — when a client asks "who changed the firewall rules on our gateway last Thursday?", you have a definitive answer. Second, it's your liability protection. If a client claims unauthorized changes were made, the audit trail shows exactly what happened and who initiated it.

Audit logs are tenant-scoped. One tenant's audit history is not visible to another tenant.

The MSP Workflow

Here's how a typical MSP onboards a new client with The Other Dude:

1. Create the tenant. A super_admin creates a new tenant for the client. This sets up the database isolation boundaries and generates a new encryption key in OpenBao for the tenant's credentials.
2. Create admin users. Set up admin-level accounts for your team members who will manage this client's network. If the client wants their own visibility, create viewer accounts for their contacts.
3. Add devices. Add the client's MikroTik routers by IP address. The platform will connect via the RouterOS API on TLS port 8729, verify connectivity, and start collecting metrics and configuration data immediately.
4. Configure monitoring. Default alert rules are created automatically — CPU, memory, disk, offline detection, wireless signal. Tune thresholds for this client's specific environment. Set up notification channels (email, Slack, webhook) for this tenant.
5. Verify backups. The automated backup system begins capturing config snapshots from the moment devices are connected. Check the backup timeline to confirm the first snapshots are arriving.
6. Delegate operator access. Create operator accounts for NOC staff who will handle day-to-day monitoring and command execution for this client's devices.

The entire process takes minutes per client. All subsequent operations — monitoring, config pushes, backup management, config editing — happen within the tenant's isolation boundary automatically.

Per-Tenant Dashboards

Each tenant gets its own fleet dashboard showing only their devices. Device counts, online/offline status, bandwidth utilization, active alerts, and wireless metrics are all scoped to the tenant. An operator logged into Client A's tenant sees only Client A's routers, alerts, and history.

For MSP operators who manage multiple clients, switching between tenants is handled through the platform's tenant context. You don't maintain separate logins or browser sessions per client — you switch context within the same interface.

Self-Hosted: Your Data, Your Infrastructure

The platform is self-hosted and open source. Client device credentials, configuration history, and monitoring data never leave your infrastructure. There's no cloud service receiving your clients' router passwords. For MSPs in regulated industries or those with contractual obligations around data handling, this is often a requirement rather than a preference.

Deploy via Docker Compose for smaller operations or the Kubernetes Helm chart for larger scale. The Quick Start guide walks through the full setup.