From e7af5e85abdf95fd1da73f3ad9eb09d7f292dc75 Mon Sep 17 00:00:00 2001 From: Jason Staack Date: Wed, 18 Mar 2026 06:39:48 -0500 Subject: [PATCH] feat(seo): add 6 targeted SEO pages for high-intent search phrases Co-Authored-By: Claude Opus 4.6 (1M context) --- .../manage-multiple-mikrotik-routers.html | 3 + .../docs/mikrotik-backup-solution.html | 216 +++++++++++++++++ .../docs/mikrotik-bulk-configuration.html | 228 ++++++++++++++++++ .../docs/mikrotik-centralized-management.html | 3 + .../docs/mikrotik-configuration-drift.html | 5 +- .../mikrotik-router-backup-automation.html | 2 + .../docs/mikrotik-router-monitoring.html | 2 + .../website/docs/msp-mikrotik-management.html | 219 +++++++++++++++++ .../docs/open-source-mikrotik-management.html | 3 + .../routeros-configuration-management.html | 226 +++++++++++++++++ .../docs/self-hosted-network-management.html | 225 +++++++++++++++++ docs/website/docs/winbox-alternative.html | 214 ++++++++++++++++ docs/website/sitemap.xml | 36 +++ 13 files changed, 1380 insertions(+), 2 deletions(-) create mode 100644 docs/website/docs/mikrotik-backup-solution.html create mode 100644 docs/website/docs/mikrotik-bulk-configuration.html create mode 100644 docs/website/docs/msp-mikrotik-management.html create mode 100644 docs/website/docs/routeros-configuration-management.html create mode 100644 docs/website/docs/self-hosted-network-management.html create mode 100644 docs/website/docs/winbox-alternative.html diff --git a/docs/website/docs/manage-multiple-mikrotik-routers.html b/docs/website/docs/manage-multiple-mikrotik-routers.html index 71dd742..4b1a2a9 100644 --- a/docs/website/docs/manage-multiple-mikrotik-routers.html +++ b/docs/website/docs/manage-multiple-mikrotik-routers.html @@ -182,6 +182,9 @@
  • Automate RouterOS configuration backups
  • Monitor MikroTik routers at scale
  • Centralized MikroTik management overview
    • +
  • Bulk configuration across multiple MikroTik devices
    • +
  • Multi-tenant MikroTik management for MSPs
    • +
  • Self-hosted network management with no cloud dependency
  • The Other Dude on GitHub
    • diff --git a/docs/website/docs/mikrotik-backup-solution.html b/docs/website/docs/mikrotik-backup-solution.html new file mode 100644 index 0000000..fb4b6d5 --- /dev/null +++ b/docs/website/docs/mikrotik-backup-solution.html @@ -0,0 +1,216 @@ + + + + + + MikroTik Backup Solution — Automated RouterOS Config Backups + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    + ← Back to Docs + +

    MikroTik Backup Solution

    + +

    The Problem with MikroTik Backups

    + +

    Router backups should be the simplest operational task in network management. In practice, they're one of the most commonly broken. The typical MikroTik backup setup involves a Scheduler script on each device that runs /system backup save or /export and sends the result to an FTP server. This works until it doesn't — and the failure modes are almost always silent.

    + +

    The FTP server's disk fills up. A firmware upgrade changes the Scheduler syntax. Someone changes the FTP password on the server but not on the 200 routers pushing to it. A device gets replaced and nobody copies the Scheduler script to the new one. In every case, backups stop arriving and nobody notices until the moment they need one.

    + +

    Even when the backups are running, the result is a pile of text files in a directory. Finding what changed between Tuesday and Thursday means manually diffing two exports. Figuring out when a specific firewall rule was added means reading through dozens of exports chronologically. Restoring a previous config means copying the export text, SSHing into the router, and pasting it — hoping the import doesn't fail halfway through on a syntax difference between firmware versions.

    + +

    This isn't a backup solution. It's a backup hope.

    + +

    What a Real Backup Solution Requires

    + +

    A mikrotik backup solution that actually works in production needs to address the specific failure modes of DIY approaches:

    + +
      +
    • Centralized scheduling. Backups should be triggered from the management platform, not from per-device Scheduler scripts. One schedule, applied fleet-wide. No per-device configuration to maintain or break.
      • +
    • Version history, not just snapshots. Every backup should be a point in the device's config timeline. You should be able to navigate that timeline, see exactly what changed at each point, and compare any two versions.
      • +
    • Diff capability. Side-by-side comparison showing added, removed, and modified lines between any two config versions. This is the difference between "something changed" and "this specific firewall rule was modified."
      • +
    • Tested restore path. A backup you can't restore isn't a backup. The restore mechanism should be built into the platform, not a manual copy-paste-SSH workflow.
      • +
    • Failure alerting. If a backup fails — device unreachable, API timeout, storage error — someone needs to know immediately, not six months later when they need the backup.
      • +
    • Fleet-wide coverage. The system should work identically for ten devices or a thousand. Adding a new device to the fleet should automatically include it in the backup schedule.
      • +
    + +

    How The Other Dude Handles Backups

    + +

    The Other Dude's backup system is built on the same Go-based poller that handles monitoring and command execution. It connects to each device via the RouterOS binary API over TLS (port 8729) and retrieves a full /export on a configurable schedule — every six hours by default.

    + +

    There are no per-device Scheduler scripts to maintain. No FTP server. No per-device backup configuration at all. Every device that's connected to the platform is automatically included in the backup schedule from the moment it's added.

    + +

    Git-Backed Version History

    + +

    Config exports are stored with complete version history in PostgreSQL. Every backup is a timestamped snapshot. The system compares each new snapshot to the previous one and records the diff. Nothing is overwritten — you have a complete timeline of every configuration state the device has been in since it was added to the platform.

    + +

    This is functionally equivalent to having every config change committed to a git repository with a timestamp and a diff. You can navigate the timeline to answer questions like "what did this router's config look like on March 3rd?" or "when was this NAT rule first added?" without reading through raw export files.

    + +

    Side-by-Side Diffs

    + +

    The web UI includes a diff viewer that shows two config versions side by side with additions highlighted in green, removals in red, and unchanged lines in grey. Select any two snapshots for a device — or compare configs across two different devices — and see exactly what differs.

    + +

    This is particularly useful for configuration drift detection. When a device's config changes between backup cycles due to an out-of-band WinBox or SSH change, the diff shows exactly what was modified. Combined with the platform's audit trail, you can distinguish between authorized changes pushed through the platform and unauthorized changes made directly on the device.

    + +

    One-Click Restore

    + +

    Select any previous backup from the timeline and push it back to the device. The restore uses the same two-phase commit mechanism as all config pushes: the config is applied, the platform verifies the device is still reachable, and if the device goes silent (indicating the restore broke connectivity), the change is automatically reverted.

    + +

    This means you can restore a previous config to a remote device with confidence that you won't lock yourself out. If the restored config breaks the management path, the device reverts to its pre-restore state automatically.

    + +

    Binary Export Download

    + +

    In addition to text-based config exports, the platform supports downloading binary .backup files for full device restore scenarios. Binary backups capture passwords, certificates, and other data that text exports omit. These are useful as a disaster recovery artifact when you need to rebuild a device from scratch on identical hardware.

    + +

    Change Detection Between Cycles

    + +

    The backup system doesn't only run on the scheduled interval. The poller detects configuration changes via NATS events, so a change made through WinBox or SSH between scheduled backup cycles will trigger an additional snapshot capture. This means the version timeline reflects actual change events, not just periodic snapshots that might miss intermediate states.

    + +

    Config Push Rollback as a Safety Net

    + +

    Backups and config management work together as complementary safety mechanisms. The backup system gives you a timeline of every previous state. The config push system's two-phase commit gives you automatic rollback on bad changes. Together, they mean you always have both a way to undo a recent change automatically and a full history to restore from manually.

    + +

    For MSPs managing multiple clients, the backup system is tenant-scoped. Each client's backup history is isolated. Backup schedules, retention policies, and restore operations all operate within tenant boundaries.

    + +

    Getting Started

    + +

    Backups start automatically when you add a device to the platform. There's no additional setup required. The Quick Start guide covers deploying the platform and connecting your first device — at which point the first config backup will be captured within minutes.

    + +

    For a deeper look at the backup automation architecture and how it handles edge cases like unreachable devices and firmware version differences, see the detailed backup automation guide.

    + +
    +

    Related

    + +
    + +
    +
    + +
    +
    +
    + + © 2026 The Other Dude. All rights reserved. +
    + +
    +

    This site uses a self-hosted, cookie-free analytics pixel to count page views. No personal data is collected or shared with third parties.

    +
    + + + + diff --git a/docs/website/docs/mikrotik-bulk-configuration.html b/docs/website/docs/mikrotik-bulk-configuration.html new file mode 100644 index 0000000..cedc794 --- /dev/null +++ b/docs/website/docs/mikrotik-bulk-configuration.html @@ -0,0 +1,228 @@ + + + + + + MikroTik Bulk Configuration — Fleet-Wide Config Management + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    + ← Back to Docs + +

    MikroTik Bulk Configuration

    + +

    The Problem: One Device at a Time

    + +

    RouterOS was designed for single-device administration. WinBox opens one session to one router. The RouterOS API connects to one device at a time. SSH gives you one terminal to one device. When you need to push a DNS server change to 200 routers, or add a firewall rule across every device at a site, you're either opening 200 individual sessions or writing a script that loops SSH connections and hopes for the best.

    + +

    The script approach works for simple cases but breaks down quickly. Error handling becomes your problem: what happens when device 47 of 200 times out? Do you retry? Skip it? Abort the whole batch? What about partial failures where the command runs but produces an unexpected result? SSH scripts don't give you per-device result reporting, rollback capability, or an audit trail. You get stdout and stderr and that's it.

    + +

    For MSPs and network teams managing MikroTik fleets, mikrotik bulk configuration isn't a nice-to-have — it's the difference between a fifteen-minute operation and a full afternoon of manual work with a spreadsheet tracking which devices you've hit and which you haven't.

    + +

    Bulk CLI Command Execution

    + +

    The Other Dude lets you run RouterOS CLI commands across multiple devices simultaneously from the web UI. Select a group of devices (by tag, site, or manual selection), enter a command, and execute. Each device gets its own result — success with output, failure with error details, or timeout.

    + +

    This is available to users with operator role or above. The RBAC system ensures that viewer-level users can't execute commands, even if they can see the devices.

    + +

    Practical use cases for bulk CLI execution:

    + +
      +
    • Fleet-wide queries. Run /system resource print across all devices to check firmware versions, uptime, and resource usage in one operation.
      • +
    • Quick fixes. Add a DNS entry, disable a problematic service, or modify an SNMP community string across a device group without writing a script.
      • +
    • Diagnostic collection. Run /interface print stats or /ip firewall connection print count-only across a site's devices to gather diagnostic data for troubleshooting.
      • +
    • Scripted maintenance. Execute RouterOS scripts that are too simple to warrant a template but need to run on multiple devices — clearing log entries, resetting connection tracking counters, or flushing DNS cache.
      • +
    + +

    Every bulk command execution is logged in the audit trail with the user, timestamp, target devices, command text, and per-device results.

    + +

    Config Templates with Variable Substitution

    + +

    For structured configuration changes, The Other Dude provides a template system. A config template is a set of RouterOS commands with placeholder variables that get substituted per device at push time.

    + +

    For example, a branch office firewall template might define standard firewall rules, NAT configuration, and DHCP settings, with variables for the site's WAN IP, LAN subnet, and gateway address. You define the template once. When you push it to a group of devices, each device gets the template rendered with its own variable values.

    + +

    The template workflow:

    + +
      +
    1. Write the template. Define the RouterOS commands with variable placeholders. The template editor in the web UI supports syntax highlighting and validation.
      2. +
    2. Preview per device. Before pushing, preview what the rendered template looks like for each target device. This shows you exactly which commands will be sent to each device with all variables substituted. No surprises.
      3. +
    3. Push to a group. Select the target devices and execute. The platform sends the rendered commands to each device in parallel.
      4. +
    4. Monitor results. Each device reports its own result. Success means all commands executed without error. Failure includes the specific error from RouterOS. The results view shows the full picture across all target devices.
      5. +
    + +

    Templates are reusable. A standard firewall ruleset, a VPN configuration, a monitoring agent setup — define it once and apply it across new devices as you add them to the fleet.

    + +

    Two-Phase Commit with Automatic Rollback

    + +

    Bulk config pushes use the same two-phase commit mechanism as single-device config changes. For each device in the batch:

    + +
      +
    1. The config change is applied to the device.
      2. +
    2. The platform waits for confirmation that the device is still reachable.
      3. +
    3. If the device remains reachable, the change is confirmed.
      4. +
    4. If the device becomes unreachable — indicating the change broke the management path — the device automatically reverts to its previous configuration.
      5. +
    + +

    This is critical for bulk operations because the blast radius of a bad config push scales with the number of target devices. A firewall rule that accidentally blocks the management subnet would lock you out of every device you pushed it to. With two-phase commit, each device independently detects the problem and reverts itself. You don't need to drive to a site or find an out-of-band console connection.

    + +

    The rollback is per-device, not per-batch. If a change succeeds on 48 of 50 devices and fails on 2, the 2 failing devices revert while the 48 successful devices keep the new config. You get a clear report of which devices succeeded and which reverted, and you can investigate the failures individually.

    + +

    Batch Config Push via the Config Editor

    + +

    In addition to templates and CLI commands, the platform's config editor supports batch operations. You can browse the RouterOS path tree, make a change, and push it to multiple devices at once. This is useful for structured changes that don't warrant a full template — adding a single firewall rule, modifying a DNS setting, or updating an NTP server across a device group.

    + +

    How This Differs from SSH Scripts

    + +

    The common alternative to a bulk configuration platform is a set of SSH scripts — Bash, Python with Paramiko, or Ansible playbooks. These can work, but they leave several problems for you to solve:

    + +
      +
    • Error handling. SSH scripts need explicit handling for connection timeouts, authentication failures, command errors, and partial execution. The platform handles this per-device automatically.
      • +
    • Rollback. SSH scripts don't have a rollback mechanism. If a command locks you out, you're locked out. The platform's two-phase commit reverts bad changes automatically.
      • +
    • Audit trail. SSH scripts produce log files at best. The platform records every operation with user attribution, timestamps, and per-device results in a queryable audit log.
      • +
    • Access control. SSH scripts run under whoever's credentials are in the script. The platform enforces RBAC — an operator can run bulk commands but a viewer can't.
      • +
    • State management. Tracking which devices got the change and which didn't is your problem with scripts. The platform gives you a per-device results view for every operation.
      • +
    + +

    Scripts solve the "run a command on many devices" problem. A platform solves the "operate a fleet safely and accountably" problem.

    + +

    Getting Started

    + +

    Bulk operations are available immediately when devices are connected to the platform. The Quick Start guide covers deploying the platform and adding your first devices. Once you have devices connected, bulk CLI execution and config push operations are available from the fleet view.

    + +
    +

    Related

    + +
    + +
    +
    + +
    +
    +
    + + © 2026 The Other Dude. All rights reserved. +
    + +
    +

    This site uses a self-hosted, cookie-free analytics pixel to count page views. No personal data is collected or shared with third parties.

    +
    + + + + diff --git a/docs/website/docs/mikrotik-centralized-management.html b/docs/website/docs/mikrotik-centralized-management.html index f39cc94..0e83f3c 100644 --- a/docs/website/docs/mikrotik-centralized-management.html +++ b/docs/website/docs/mikrotik-centralized-management.html @@ -156,6 +156,9 @@
  • Managing multiple MikroTik routers from one interface
  • Monitoring MikroTik routers at scale
  • Why open source matters for MikroTik management
    • +
  • RouterOS configuration management with safe rollback
    • +
  • Multi-tenant MikroTik management for MSPs
    • +
  • Browser-based WinBox alternative
  • The Other Dude on GitHub
    • diff --git a/docs/website/docs/mikrotik-configuration-drift.html b/docs/website/docs/mikrotik-configuration-drift.html index 85c25f2..5bef7e4 100644 --- a/docs/website/docs/mikrotik-configuration-drift.html +++ b/docs/website/docs/mikrotik-configuration-drift.html @@ -128,10 +128,11 @@
  • Manage multiple MikroTik routers
  • Monitor MikroTik routers at scale
  • MikroTik centralized management
    • +
  • RouterOS configuration management with safe rollback
    • +
  • Automated MikroTik backup solution
    • +
  • View on GitHub
    • -

    View on GitHub

    - diff --git a/docs/website/docs/mikrotik-router-backup-automation.html b/docs/website/docs/mikrotik-router-backup-automation.html index 6f162e3..186dd0f 100644 --- a/docs/website/docs/mikrotik-router-backup-automation.html +++ b/docs/website/docs/mikrotik-router-backup-automation.html @@ -156,6 +156,8 @@
  • How to manage multiple MikroTik routers — fleet management strategies for MSPs and network teams
  • How to monitor MikroTik routers at scale — metrics collection, alerting, and health dashboards
  • MikroTik centralized management — multi-site visibility, bulk operations, and unified access
    • +
  • MikroTik backup solution — overview of the backup system with git-backed history and one-click restore
    • +
  • RouterOS configuration management — safe config pushes with two-phase commit and rollback
  • The Other Dude on GitHub — source code, issue tracker, and release notes
    • diff --git a/docs/website/docs/mikrotik-router-monitoring.html b/docs/website/docs/mikrotik-router-monitoring.html index cd7cedd..123af6f 100644 --- a/docs/website/docs/mikrotik-router-monitoring.html +++ b/docs/website/docs/mikrotik-router-monitoring.html @@ -166,6 +166,8 @@
  • Automate router backups for every device
  • Manage multiple MikroTik routers from one interface
  • MikroTik centralized management: architecture and setup
    • +
  • Self-hosted network management with no cloud dependency
    • +
  • Multi-tenant MikroTik management for MSPs
  • The Other Dude on GitHub
    • diff --git a/docs/website/docs/msp-mikrotik-management.html b/docs/website/docs/msp-mikrotik-management.html new file mode 100644 index 0000000..4e50749 --- /dev/null +++ b/docs/website/docs/msp-mikrotik-management.html @@ -0,0 +1,219 @@ + + + + + + MikroTik Management for MSPs — Multi-Tenant Fleet Platform + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    + ← Back to Docs + +

    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. +
    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. +
    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. +
    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. +
    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. +
    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.
      7. +
    + +

    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.

    + +
    +

    Related

    + +
    + +
    +
    + +
    +
    +
    + + © 2026 The Other Dude. All rights reserved. +
    + +
    +

    This site uses a self-hosted, cookie-free analytics pixel to count page views. No personal data is collected or shared with third parties.

    +
    + + + + diff --git a/docs/website/docs/open-source-mikrotik-management.html b/docs/website/docs/open-source-mikrotik-management.html index 61bd3b0..1359dd4 100644 --- a/docs/website/docs/open-source-mikrotik-management.html +++ b/docs/website/docs/open-source-mikrotik-management.html @@ -162,6 +162,9 @@
  • Monitoring MikroTik routers at scale
  • Automate RouterOS config backups
  • Why This Exists (blog)
    • +
  • Self-hosted network management with no cloud dependency
    • +
  • Browser-based WinBox alternative
    • +
  • Bulk configuration across multiple MikroTik devices
  • What You Can Do With It Today (blog)
  • View on GitHub
    • diff --git a/docs/website/docs/routeros-configuration-management.html b/docs/website/docs/routeros-configuration-management.html new file mode 100644 index 0000000..e6efc1b --- /dev/null +++ b/docs/website/docs/routeros-configuration-management.html @@ -0,0 +1,226 @@ + + + + + + RouterOS Configuration Management — Safe Config Pushes with Rollback + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    + ← Back to Docs + +

    RouterOS Configuration Management

    + +

    The Core Problem: Config Changes Are Dangerous

    + +

    Every network engineer has a story about a config change that went wrong. You add a firewall rule that accidentally blocks the management subnet. You modify a routing table entry and lose the return path to the device. You push an IP change to a remote router and realize, too late, that you just cut off your own access.

    + +

    With RouterOS, these scenarios are especially common because changes take effect immediately. There's no staging area, no "apply and confirm" mechanism in WinBox or the CLI. The moment you hit enter, the change is live. If that change breaks your management path, you're locked out until someone physically accesses the device or you reach it through an out-of-band connection.

    + +

    This is the fundamental problem that routeros configuration management needs to solve: making config changes safe, reversible, and auditable.

    + +

    The Config Editor

    + +

    The Other Dude provides a web-based config editor that exposes the full RouterOS path hierarchy — the same tree structure you navigate in WinBox. You browse /ip/address, /ip/firewall/filter, /interface, /routing/ospf, and every other RouterOS path from the web UI.

    + +

    The config editor reads the current state of each path directly from the device via the RouterOS binary API. What you see in the editor is the live running configuration, not a cached snapshot. You can view entries, add new ones, modify existing ones, or remove them — the same operations WinBox provides, but through a browser.

    + +

    The advantage over WinBox isn't the interface — WinBox is faster for single-device work. The advantage is everything that wraps around the edit: rollback protection, version history, audit logging, RBAC enforcement, and the ability to push the same change to multiple devices.

    + +

    Two-Phase Commit: The Safety Net

    + +

    This is the most important feature in the config management system. Every config push — whether from the editor, a template, or a bulk operation — uses a two-phase commit process:

    + +
      +
    1. Apply. The config change is sent to the device and takes effect immediately, as RouterOS requires.
      2. +
    2. Verify. The platform waits for a configurable confirmation period, continuously checking that the device is still reachable via the API.
      3. +
    3. Confirm or revert. If the device remains reachable throughout the confirmation period, the change is committed as permanent. If the device becomes unreachable at any point during the confirmation period — indicating the change broke the management path — the device automatically reverts to its pre-change configuration.
      4. +
    + +

    The revert mechanism uses RouterOS's built-in safe mode capabilities. The platform sets up a revert timer before applying the change. If the platform confirms the change successfully, it cancels the timer. If the platform loses contact with the device, the timer expires and RouterOS reverts the change on its own.

    + +

    This means you can push a firewall rule to a remote router with confidence. If the rule blocks your management traffic, the router will revert itself. You don't need to call someone to reboot it. You don't need a serial console. The safety net is built into the push mechanism itself.

    + +

    Git-Backed Version History

    + +

    Every config state is stored with full version history in PostgreSQL. When a config change is pushed through the platform, the before and after states are recorded along with a diff, the user who made the change, and a timestamp. When a change is detected from an out-of-band modification (someone used WinBox or SSH directly), the new state is captured on the next polling cycle.

    + +

    The version history gives you:

    + +
      +
    • A complete timeline. Navigate through every configuration state the device has been in since it was added to the platform.
      • +
    • Side-by-side diffs. Compare any two versions and see exactly what changed — additions, removals, and modifications highlighted line by line.
      • +
    • Cross-device comparison. Compare the config of two different devices to identify configuration drift or verify consistency across a group.
      • +
    • One-click restore. Select any previous version and push it back to the device, using the same two-phase commit mechanism for safety.
      • +
    + +

    This is functionally equivalent to having every config change committed to a git repository. You get the audit trail, the diff capability, and the ability to roll back — without requiring engineers to use git directly.

    + +

    Simple Mode for Common Tasks

    + +

    Not every config change requires navigating the full RouterOS path tree. The config editor includes a Simple Mode that provides a streamlined interface for the most common tasks: IP addressing, DHCP configuration, basic firewall rules, DNS settings, and interface management.

    + +

    Simple Mode is modeled after consumer router interfaces — fill in the fields, click apply. Under the hood, it generates the same RouterOS commands and uses the same two-phase commit mechanism. The safety guarantees are identical; only the UI complexity is reduced.

    + +

    This is particularly useful for MSPs with operator-level staff who need to handle common tasks without deep RouterOS expertise. An operator can change a DHCP pool or add a port forward through Simple Mode without needing to know the exact RouterOS path syntax.

    + +

    Template System

    + +

    For fleet-wide configuration changes, the template system lets you define a set of RouterOS commands with variable placeholders. Variables are substituted per-device at push time, allowing a single template to be applied across devices with different IP ranges, interface names, or site-specific values.

    + +

    Templates combine with two-phase commit for safe bulk operations. Each device in the batch independently verifies the change and reverts if needed. A template push to 50 devices will succeed on the devices where the change works and revert on any where it doesn't.

    + +

    How This Differs from SSH Scripts and Ansible

    + +

    The most common alternative to a config management platform is SSH scripting — either raw Bash/Python scripts or Ansible playbooks with the routeros modules. These approaches can work, but they require you to solve several problems yourself:

    + +
      +
    • No rollback. SSH scripts apply changes. If the change locks you out, you're locked out. There's no built-in safety net. Ansible's routeros modules don't implement two-phase commit.
      • +
    • No version history. Scripts produce the desired end state. They don't track what the config was before, what changed, or when. That's a separate system you'd need to build.
      • +
    • No UI for browsing. Scripts push changes. They don't let you browse the current config tree, compare versions, or preview what will change before you apply it.
      • +
    • Limited error context. SSH scripts give you exit codes and stderr. The platform gives you per-device success/failure with detailed error messages, rendered in a UI that shows the full batch result at a glance.
      • +
    • No RBAC. Scripts run under whoever has the credentials. The platform enforces role-based access — viewers can't push, operators can push but can't manage users, admins have full control.
      • +
    + +

    For teams with strong automation skills and simple requirements, scripts may be sufficient. For fleet-scale operations where safety, auditability, and access control matter, a purpose-built config management platform eliminates the infrastructure you'd otherwise need to build and maintain yourself.

    + +

    Getting Started

    + +

    The config editor and two-phase commit are available immediately when a device is connected to the platform. The Quick Start guide covers deploying the platform and connecting your first device. Once connected, you can browse the device's config tree, make changes with rollback protection, and see the first backup appear in the version history.

    + +
    +

    Related

    + +
    + +
    +
    + +
    +
    +
    + + © 2026 The Other Dude. All rights reserved. +
    + +
    +

    This site uses a self-hosted, cookie-free analytics pixel to count page views. No personal data is collected or shared with third parties.

    +
    + + + + diff --git a/docs/website/docs/self-hosted-network-management.html b/docs/website/docs/self-hosted-network-management.html new file mode 100644 index 0000000..e481514 --- /dev/null +++ b/docs/website/docs/self-hosted-network-management.html @@ -0,0 +1,225 @@ + + + + + + Self-Hosted Network Management — No Cloud, No Vendor Lock-In + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    + ← Back to Docs + +

    Self-Hosted Network Management

    + +

    Why Self-Hosting Matters for Network Management

    + +

    Network management platforms occupy a uniquely sensitive position in your infrastructure. They store device credentials — the SSH passwords and API keys that provide direct access to every router in your fleet. They store configuration data — the complete running state of every managed device. They store monitoring history — traffic patterns, bandwidth utilization, and device health data that reveals your network's architecture and capacity.

    + +

    When you use a cloud-hosted network management service, all of this data lives on someone else's infrastructure. Your router passwords are stored in someone else's database. Your config history is backed up to someone else's object store. Your monitoring data flows through someone else's ingestion pipeline.

    + +

    For many organizations, this is a non-starter. MSPs with contractual obligations around client data handling can't send device credentials to a third party. ISPs in regulated markets may have compliance requirements around where network infrastructure data is stored. Government and defense contractors operate under frameworks that prohibit cloud-hosted management of network devices. Even without formal compliance requirements, sending your complete device credential set to a SaaS platform is a risk that many network engineers are uncomfortable with.

    + +

    Self-hosted network management eliminates this class of risk entirely. Your data stays on your hardware, behind your firewall, under your control.

    + +

    Deployment Options

    + +

    Docker Compose

    + +

    The primary deployment method is Docker Compose. A single docker-compose.yml file brings up the entire stack: the React frontend, the FastAPI backend, the Go poller, PostgreSQL with TimescaleDB, Redis, NATS JetStream, and OpenBao for credential encryption.

    + +

    Prerequisites are minimal: a Linux host (or macOS for development) with Docker and Docker Compose installed. The included setup wizard (setup.py) walks through initial configuration — database credentials, admin user creation, and basic platform settings. From clone to running platform with your first connected device takes about ten minutes.

    + +

    Docker Compose is the right choice for most deployments. Single-server installations handling up to several hundred devices run comfortably on modest hardware. The compose file handles container orchestration, networking between services, and volume management for persistent data.

    + +

    Kubernetes via Helm Chart

    + +

    For organizations that run Kubernetes, the project includes a Helm chart. This provides the same stack deployed as Kubernetes resources: Deployments, Services, ConfigMaps, Secrets, and PersistentVolumeClaims.

    + +

    The Helm chart is useful for teams that want to integrate the platform into existing Kubernetes infrastructure, take advantage of Kubernetes features like auto-restart and resource limits, or deploy across multiple nodes for availability. It's not required — Docker Compose is simpler and sufficient for most use cases.

    + +

    What Runs on Your Infrastructure

    + +

    Everything. There is no external service dependency for core functionality. Here's what the stack includes:

    + +
      +
    • PostgreSQL + TimescaleDB — All device data, config history, user accounts, audit logs, and time-series metrics are stored in PostgreSQL. TimescaleDB extensions handle the high-frequency metric data efficiently.
      • +
    • Redis — Session caching, rate limiting, and ephemeral state. No persistent data — Redis can be flushed without data loss.
      • +
    • NATS JetStream — Real-time event bus between the poller and backend. Device status changes, metric updates, and command results flow through NATS. Also provides durable streams for reliable delivery.
      • +
    • OpenBao — Manages encryption keys for device credentials. Per-tenant envelope encryption means each tenant's credentials are encrypted with a unique key. OpenBao runs as a container within the stack — no external vault service required.
      • +
    • Go Poller — Connects to MikroTik devices via the RouterOS binary API over TLS (port 8729). Handles metric collection, config backup retrieval, command execution, and health monitoring. Maintains persistent connections with automatic reconnection.
      • +
    • FastAPI Backend — REST API, authentication (SRP-6a zero-knowledge protocol), RBAC enforcement, task orchestration, and SSE for real-time browser updates.
      • +
    • React Frontend — The web UI. Fleet dashboard, config editor, monitoring views, WinBox-in-browser, SSH terminal, and all management interfaces.
      • +
    + +

    No Cloud Dependency

    + +

    The platform makes no outbound network connections for its core functionality. There is no license server to validate against. There is no cloud API that needs to be reachable. There is no telemetry that phones home by default.

    + +

    The single optional external connection is a check for new MikroTik firmware versions, which queries MikroTik's public version endpoint. This is disabled by default and only used to show firmware update availability in the fleet view. Disabling it has no impact on functionality.

    + +

    Optional anonymous telemetry is available for development diagnostics — it's disabled by default, opt-in only, and the exact data it would collect is documented in the source code so you can inspect it before enabling. No usage tracking, no analytics, no data collection that you haven't explicitly opted into.

    + +

    Air-Gapped Deployment

    + +

    Because there are no external dependencies, the platform can run in air-gapped environments with no internet access. Pull the Docker images on a connected machine, transfer them to the isolated network, and deploy. The platform functions identically whether it has internet access or not.

    + +

    This is relevant for government networks, classified environments, industrial control system networks, and other contexts where internet connectivity is either unavailable or prohibited for management infrastructure.

    + +

    Comparison with Cloud-Hosted Alternatives

    + +

    Cloud-hosted network management platforms solve real problems and many are well-engineered. The tradeoff is the trust model:

    + +
      +
    • Credential exposure. Cloud platforms need your device credentials to connect to your routers. Those credentials are stored on infrastructure you don't control, protected by security practices you can't audit (unless the platform is open source, which most commercial ones aren't).
      • +
    • Data sovereignty. Config history, monitoring data, and audit logs live in the provider's cloud. Depending on your jurisdiction and your clients' requirements, this may conflict with data residency obligations.
      • +
    • Vendor lock-in. Your operational history — config versions, monitoring trends, audit trails — is in the provider's database. Switching platforms means losing that history or undertaking a complex data export.
      • +
    • Availability dependency. If the cloud provider has an outage, your network management goes offline. Your routers keep running, but you lose visibility and management capability until the service recovers.
      • +
    • Cost scaling. Cloud platforms typically charge per device per month. At fleet scale, this adds up. A self-hosted platform's cost is the hardware it runs on, which you likely already have.
      • +
    + +

    Self-hosted management trades operational convenience (someone else runs the infrastructure) for control (you run the infrastructure, you own the data, you control access). For network management specifically — where the platform holds the keys to your entire routing infrastructure — that tradeoff often favors self-hosting.

    + +

    Open Source

    + +

    The platform is open source and available on GitHub. You can audit the code that touches your device credentials. You can verify the encryption implementation. You can read exactly what API calls the poller makes to your routers. Self-hosted plus open source means you have both operational control and code-level transparency.

    + +

    Getting Started

    + +

    The Quick Start guide covers the full deployment process. Clone the repository, run the setup wizard, connect your first device. The platform is running on your infrastructure in about ten minutes.

    + +
    +

    Related

    + +
    + +
    +
    + +
    +
    +
    + + © 2026 The Other Dude. All rights reserved. +
    + +
    +

    This site uses a self-hosted, cookie-free analytics pixel to count page views. No personal data is collected or shared with third parties.

    +
    + + + + diff --git a/docs/website/docs/winbox-alternative.html b/docs/website/docs/winbox-alternative.html new file mode 100644 index 0000000..bbc9cec --- /dev/null +++ b/docs/website/docs/winbox-alternative.html @@ -0,0 +1,214 @@ + + + + + + WinBox Alternative — Browser-Based MikroTik Management + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    + ← Back to Docs + +

    WinBox Alternative — Browser-Based MikroTik Management

    + +

    What WinBox Does Well

    + +

    WinBox is genuinely excellent at what it was built for. It provides fast, low-latency access to a single MikroTik router's full configuration. The tree-based interface mirrors the RouterOS path hierarchy exactly. You can drag firewall rules, monitor traffic in real time with Torch, and edit any config section with immediate feedback. For hands-on work on one device, nothing beats it.

    + +

    MikroTik engineers have used WinBox since the early RouterOS days, and for good reason. It's purpose-built, responsive, and gives you complete access to every RouterOS feature. If you manage one router, or a small handful, WinBox is the right tool.

    + +

    Where WinBox Stops Working

    + +

    The problem starts at scale. WinBox is a single-device tool. There's no fleet view, no way to push a config change to fifty routers at once, no version history, no audit trail of who changed what. Every session is independent — no shared state between them.

    + +

    For MSPs managing client networks or ISPs running hundreds of CPE devices, WinBox creates specific operational problems:

    + +
      +
    • No batch operations. Changing a DNS server across 200 routers means 200 individual WinBox sessions. Even with MAC-Telnet or the RouterOS API, you're scripting each connection yourself.
      • +
    • No configuration history. WinBox shows you the current state. If someone changed a firewall rule last Tuesday, WinBox can't tell you what it was before.
      • +
    • No fleet visibility. You can't ask "which of my 300 routers have CPU above 80% right now?" without opening 300 connections.
      • +
    • Client installation required. WinBox needs to be installed on each workstation. It runs on Windows natively, with Wine or Crossover on macOS and Linux. For remote access scenarios or shared operations, that's friction.
      • +
    • No RBAC. WinBox authenticates directly to each router. There's no way to give an operator read-only access to device monitoring while restricting config changes — that requires per-device user setup.
      • +
    + +

    None of this is a failure of WinBox. It was designed as a single-device administration tool, and it's the best one in the RouterOS ecosystem. The gap is everything above that: fleet-level operations, history, security, and collaboration.

    + +

    WinBox in the Browser

    + +

    The Other Dude includes a browser-based WinBox feature that runs actual WinBox sessions inside your web browser. This is not a WinBox emulation or a simplified web UI pretending to be WinBox. It launches a real WinBox instance inside a container and streams the session to your browser via SSH tunneling.

    + +

    Here's how it works: when you open a WinBox session for a device from the fleet dashboard, the platform spins up a containerized WinBox instance, establishes an SSH tunnel to the target router, and renders the WinBox GUI in your browser window. You get the full WinBox experience — the same tree navigation, the same real-time tools, the same configuration interface — without installing anything on your local machine.

    + +

    This matters for several practical reasons:

    + +
      +
    • No client software. Any device with a modern web browser can run a WinBox session. This works from a Chromebook, an iPad, a Linux workstation, or a locked-down corporate laptop where you can't install software.
      • +
    • Centralized credential handling. Device credentials are managed by the platform and encrypted at rest with AES-256-GCM via OpenBao Transit. You don't need to distribute router passwords to every engineer's workstation.
      • +
    • Audit trail. Every WinBox session launch is logged — who opened it, when, to which device. Combined with the platform's config backup system, you can correlate WinBox access with config changes detected on the next polling cycle.
      • +
    • Access control. WinBox sessions are gated by RBAC. An operator with viewer-level access can't launch a WinBox session. The platform enforces who can do what, even for direct device access.
      • +
    + +

    SSH Terminal in the Browser

    + +

    Alongside browser-based WinBox, the platform provides an in-browser SSH terminal to any managed device. This is useful for CLI-oriented tasks — running /export, checking /system resource print, or executing RouterOS scripts directly.

    + +

    The SSH terminal uses the same credential management and RBAC enforcement as WinBox sessions. No need to maintain SSH keys on individual workstations or distribute device passwords through side channels.

    + +

    Fleet Management Around WinBox

    + +

    The intent is not to replace WinBox for hands-on device work. WinBox is the right tool when you need to dig into a single router's config, debug a routing issue, or tune firewall rules interactively. What The Other Dude adds is everything around that:

    + +

    Fleet dashboard. See all your devices in one view — online/offline status, CPU, memory, bandwidth utilization, uptime, firmware version. Filter by group, site, or alert status. The device table uses virtual scrolling to handle hundreds of routers without performance degradation.

    + +

    Configuration management. Browse and edit the RouterOS config tree from the web UI, with two-phase commit and automatic rollback. Every change is stored in git-backed version history with full diff capability. Templates let you define a config once and push it to a group of devices with per-device variable substitution.

    + +

    Automated backups. The platform captures a full config export from every device on a configurable schedule. Navigate the version timeline, compare any two snapshots side by side, restore with one click.

    + +

    Monitoring and alerts. CPU, memory, traffic, and wireless metrics stored in TimescaleDB with threshold-based alerting. Maintenance windows suppress alerts during planned work.

    + +

    Bulk operations. Push config changes or run CLI commands across a group of devices simultaneously. Each device gets its own result with success/failure reporting.

    + +

    Multi-tenant isolation. MSPs can manage multiple clients from one platform with hard tenant boundaries enforced at the database level.

    + +

    No Client Install Needed

    + +

    The entire platform — fleet dashboard, config editor, WinBox sessions, SSH terminal, monitoring, backups — runs in a web browser. Deploy the platform on your infrastructure via Docker Compose or the Kubernetes Helm chart, and every engineer on your team has access from any device with a browser. No WinBox installation, no SSH key distribution, no VPN client for each operations workstation.

    + +

    The platform is open source and self-hosted. Your device credentials, config history, and monitoring data stay on your infrastructure. Full setup takes about ten minutes — the Quick Start guide covers the process from clone to first connected device.

    + +
    +

    Related

    + +
    + +
    +
    + +
    +
    +
    + + © 2026 The Other Dude. All rights reserved. +
    + +
    +

    This site uses a self-hosted, cookie-free analytics pixel to count page views. No personal data is collected or shared with third parties.

    +
    + + + + diff --git a/docs/website/sitemap.xml b/docs/website/sitemap.xml index a396d25..b565dc2 100644 --- a/docs/website/sitemap.xml +++ b/docs/website/sitemap.xml @@ -78,4 +78,40 @@ monthly 0.8 + + https://theotherdude.net/docs/winbox-alternative.html + 2026-03-18 + monthly + 0.7 + + + https://theotherdude.net/docs/msp-mikrotik-management.html + 2026-03-18 + monthly + 0.7 + + + https://theotherdude.net/docs/mikrotik-backup-solution.html + 2026-03-18 + monthly + 0.7 + + + https://theotherdude.net/docs/mikrotik-bulk-configuration.html + 2026-03-18 + monthly + 0.7 + + + https://theotherdude.net/docs/routeros-configuration-management.html + 2026-03-18 + monthly + 0.7 + + + https://theotherdude.net/docs/self-hosted-network-management.html + 2026-03-18 + monthly + 0.7 +