Two pages for the same problem from opposite ends: one command you need to run on forty routers right now, and the command set you would rather not retype next quarter.
The Commands page takes one RouterOS command line and a set of devices. Targets can be picked one at a time, by site — the site checkbox toggles everything under it — or by tag: each tag becomes a chip, and clicking it selects every device carrying that tag. "All CPE", "all core", "everything at the coast" are tag questions, and tagging devices well is what makes this page quick.
Two kinds of device are absent from the list on purpose: disabled ones, and SNMP-only ones, which have no command channel at all.
Execution is sequential, one device after another, and the page does not wait for it. Each device's output appears as it finishes, and the run is recorded in the history table below with the device count and how many succeeded. That output stream is private to whoever started the run — another operator with the same page open does not see it.
The command itself is passed through as you typed it. The manager does not parse, validate or fix your syntax, so quoting is your responsibility — an interface name containing a space needs its quotes, or RouterOS answers with a syntax error that will show up in your device's own log as well as in the output here.
On devices set to the REST connection method, the command line is translated into a REST call before it is sent: print and getall become a GET, every other action verb becomes a POST, and a [find …] clause becomes a query. Devices on SSH get the line as written.
History on this page lists runs that touched more than one device. A run that spanned two sites shows a site-scoped user only their own devices and only those devices' output.
Under the command box, "Use different credentials (this run only)" takes a RouterOS username and password used for that execution and nothing else. It is there for the case where the stored account is deliberately read-only and a change needs a person's own login behind it.
Over SSH such a run gets its own connection outside the pool, used once and dropped, so the pooled connection that the sixty-second poll shares stays authenticated as the device's own stored account.
The password is not stored anywhere and does not appear in any log. The username does: the activity log records which account the run was made under, which is the entire point of the feature.
A template is a saved command set with a name, an optional description, a category — Security, Network, Services, System or General — and an enabled flag. Templates come in two types, and the type decides which button you get.
| Commands | Script | |
|---|---|---|
| Body | One command per line | A single RouterOS script, with :local, :while, comments and all |
| Button | Execute | Deploy |
| What happens | Each command runs in order on each selected device | The body is installed into /system/script and is not run |
| Recorded in | Command history, prefixed [Template] | Nothing — results stream to the page and are not kept |
Executing a template works through five devices at a time; within one device the commands run in order, so a template that disables a service and then enables its replacement stays in the sequence you wrote. A failing command does not stop the ones after it — each command reports its own result, and the summary at the end counts successes and failures across the whole run.
A Script-type template cannot be executed, only deployed. That is the point of the type: bodies with loops and variables belong on the device, run by a scheduler or by hand, not pushed through a command channel one line at a time.
Deploy asks for the name the script will have on the device — letters, digits, dot, underscore and hyphen only — and offers to replace an existing script of that name. Without that box ticked, a name that already exists is an error, not a silent overwrite.
The body travels to the router as a file rather than inline on a command line, which is what lets long scripts arrive intact: it is uploaded, added with /system/script/add reading the file's contents, checked for length, and the temporary file is removed. If the stored script comes back empty — a delivery that silently failed — the deploy reports an error for that device instead of leaving a script that does nothing.
Nothing runs. Deploying a GeoIP script to twelve routers changes no traffic until something runs it on each of them, which is exactly what the generator's optional weekly scheduler is for. The GeoIP section covers that generator in full.
Templates export as JSON, one at a time or all at once. The file carries the name, description, type, commands and category, and nothing else — no identifiers, no device references, no timestamps from the source system — so a template written on a laptop install works unchanged on a production one.
Import shows a preview before anything is written: how many templates the file holds, which names already exist, and how many commands look destructive. That last count is a keyword match on things like reset-configuration, remove, reboot and shutdown. It is a prompt to read the file, not a safety net — a template from a stranger deserves the same reading as a script from a stranger.
Where a name collides, you choose once for the whole file:
The file declares a format and a version, and an import refuses anything that is not a templates export of the version this build understands. Hand-editing an export is fine; changing its format or version line is not.
| Action | Viewer | Operator | Admin |
|---|---|---|---|
| See the template list | Yes | Yes | Yes |
| Execute a template, deploy a script | No | Yes | Yes |
| Run a mass command, read command history | No | Yes | Yes |
| Create, edit or delete a template | No | No | Yes |
| Import or export templates | No | No | Yes |
| Generate a GeoIP rule | No | No | Yes |
Site scope applies on top of the role. Both execute and deploy take their target list from the browser, so both narrow it server-side before anything runs: a device outside the caller's sites is dropped from the run rather than refused, and a run that names only such devices comes back as if none of them existed.
The four roles and how scope is assigned are covered on the Users and Access page.