← 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 a RouterOS CLI command across a group of devices from the web UI. Select the devices (by tag, site, or manual selection), enter a command, and execute. They run one at a time so you can watch the results arrive, and you can abort the run partway through if the first few outputs aren't what you expected. Each device gets its own result — success with output, failure with error details, or timeout. Offline devices are skipped rather than retried. A blocklist refuses the commands with no safe bulk use: reboot, shutdown, reset-configuration, and changes to users, passwords or certificates.

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.

Safe-Mode Rollback, Per Device

Template pushes are applied inside a RouterOS safe-mode session, one device at a time. For each device in the group:

  1. A binary backup is written to the device's own flash as an independent recovery point.
  2. The platform enters safe mode on the device and applies the change inside that session.
  3. After a settle period it dials a new connection to check the device still answers — the existing session would answer regardless, so it proves nothing.
  4. If the device answers, the session is released and the change stands.
  5. If it doesn't, the session is dropped and RouterOS reverts the change itself, without rebooting.

This matters most in bulk, because the blast radius of a bad config push scales with the number of targets. A firewall rule that accidentally blocks the management subnet would otherwise lock you out of every device you pushed it to.

Rollouts are sequential and they halt. Devices are pushed in order, and the rollout stops at the first device that fails rather than continuing into the rest of the group. So the realistic worst case is not "48 of 50 succeeded and 2 reverted" — it is a handful committed, one reverted, and the remainder never attempted. That is the second safety mechanism, and it is the one that limits how far a bad change can get. Each device takes about a minute, which is the cost of it.

One limit worth knowing before you write a large template: safe mode's undo buffer holds 100 actions, and beyond that RouterOS silently stops reverting. The platform counts the change set up front and refuses a push it could not protect, rather than applying it unprotected. Split a very large template into stages.

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 apply it to each device in a group in turn. This is convenient for structured changes that don't warrant a full template — a DNS setting or an NTP server across a device group.

Batch Config has no rollback, and that matters more here than anywhere else in the product. It runs on the config editor's path, so there is no pre-push backup and no safe-mode session, and it does not stop when a device fails — it continues through the rest of the list. A change that cuts off the management path is therefore applied to every device you selected and reverted on none of them. For anything that could affect reachability, including the firewall rule in the example above, use a template push instead: those are safe-mode protected per device and halt on the first failure.

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