← 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:

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. 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. Push to a group. Select the target devices and execute. The platform sends the rendered commands to each device in parallel.
  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.

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. The platform waits for confirmation that the device is still reachable.
  3. If the device remains reachable, the change is confirmed.
  4. If the device becomes unreachable — indicating the change broke the management path — the device automatically reverts to its previous configuration.

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:

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