Administration

Scanning a network

The Scan Network page sweeps one or more address ranges for MikroTik devices. It is an administrator action, and it takes one set of credentials for the whole scan.

Ranges can be written three ways: CIDR from /16 to /30, a dash range in either the short or the long form (192.168.88.1-254 or 192.168.88.1-192.168.88.254), or a single address. Several ranges go into one scan, separated by commas or new lines, and an address that two of them cover is scanned once (v1.104.0+). A scan of more than 65 534 addresses in all is refused rather than attempted.

Each address goes through two stages. First a plain TCP connection to up to three ports — SSH, the HTTPS API and the HTTP API — with a two-second timeout, ten addresses in flight at a time. An address where none of them answers is reported as unreachable and probed no further.

Leave a port field empty and that check is skipped: the port is not tried and no login is attempted on it, so a sweep over SSH only leaves no API logins in your routers' logs. At least one of the three has to stay. Skipped checks show as grey badges in the results rather than as failures (v1.96.0+).

Where a port does answer, the manager tries a real RouterOS system-information read using the credentials you supplied. That second stage is what separates "something is listening on port 22" from "this is a router I can manage", and it is also why the result table tells you which of SSH, REST over HTTPS and REST over HTTP actually worked, rather than just that the host is up.

No single address may hold the sweep for longer than a minute. Whatever is still outstanding on it past that is abandoned and the address is reported as not answering, so one host that accepts a connection and then goes quiet cannot stall the rest of the range.

The port fields are pre-filled from the same defaults the Add Device form uses, so an install that runs SSH on a non-standard port scans that port without being told twice. Every connection a probe opens is closed straight after it, so a sweep does not leave sessions parked on your routers.

Progress streams to the page and to the task tray as it runs, and a scan is private to the person who started it — no other session receives it, whatever their role. A device you already have is marked Exists with its name, and its tick box is disabled, so you cannot add it twice by accident. It is recognised by address, by a Host name that resolves to the scanned address, or by the serial number the router reports, which also catches a device that has moved to a new address; the name of its current entry is then shown with the address it is registered at (v1.96.0+). When the entry's Host is an IP address, an Update address button next to it moves that entry to the address the scan found; only the Host changes, and the change is recorded in the activity log. An entry added by DNS name gets a note to check DNS instead, since that is where the fix belongs. (v1.97.0+) Adding from a scan also skips any router already registered at that address and SSH port. A scan you start yourself runs once. For one that repeats on its own, see Discovery profiles.

What a scan finds is kept on the server, so reloading the page during or after a scan loses nothing, and a scan still running picks up where it is (v1.104.0+). The form comes back as you last started it, except the password, which is never stored. Each row shows when the device was last seen. If a later scan covers its address and does not find it, the row says how many scans in a row missed it. A row nobody has seen for 30 days drops off the list. Whether a device is already in the fleet is checked each time the list is shown, so one added or deleted since the scan shows as it is now.

Dismiss hides a row you do not want to add, and later scans keep it hidden, also when the same router turns up at another address. Show dismissed brings the hidden rows back into view, with a Restore button on each. Clear list empties one list; pick it in the filter next to the button first. Dismissed rows stay dismissed after a clear, and nothing in the fleet is touched.

Discovery profiles

A discovery profile is a scan you set up once and let run on its own (v1.104.0+). Use it when routers keep appearing on a set of subnets and scanning them by hand every week is the job. Profiles live in their own card on the Scan Network page, under New profile.

A profile holds a name, the ranges, the three ports, a username and password, the site that devices added from it go to, and how often it runs: every hour, every 6 or 12 hours, daily or weekly. The ranges and ports follow the same rules as a scan you start yourself. The password is stored encrypted and never shown again. When you edit a profile, leaving the field empty keeps it.

The first timed run comes one interval after you save the profile. Run now starts one straight away, and while a run is going the profile cannot be started a second time. The timer runs due profiles one after another, not side by side. The card shows when each profile last ran, how many devices it found and how many of them were new, and when it runs next. Untick Run on schedule to keep a profile without it running.

A profile never adds anything to the fleet. What it finds goes into the list on the same page, marked with the profile's name in the Found by column, and you add from there. A profile and its list are seen by the administrator who created it and by every administrator not limited to sites. A scan you start yourself stays visible to you alone. Deleting a profile deletes its list with it.

When a run finds MikroTik devices that are not in the fleet and that this profile had not found before, it sends the New Device Discovered webhook: one message for the run, listing them. The sidebar shows the number of found devices waiting to be added, next to Scan Network.

Adding what you found

Tick the rows you want, choose a site from the dropdown and Add Selected registers them. Default site puts devices from a profile on the profile's site and devices from your own scans on no site; any site you pick applies to all the selected rows. Each new device takes its name from the RouterOS identity, falling back to the board name with the address, then to the bare address. The connection method comes from the Method column of the row.

For rows from your own scans, the username and password in the scan form become the device's stored credentials. After a reload the password field is empty, so type it again before adding; if you add with it empty, the page asks first. Rows a profile found are added with the profile's username and password, which the page never sees. In both cases the ports are the ones the device answered on when it was found (v1.104.0+).

Where a device answered on more than one of the three, that column is a dropdown and REST is offered first: REST over HTTPS, then REST over HTTP, then SSH. Set it per row before adding, because the choice also decides which port and which protocol the device is stored with.

Nothing is authenticated a second time at this point — the probe that found the device is the test it passed. A password typed into the form after the sweep is saved untried. A device arrives with no status at all and reads as Unknown until the first poll reaches it.

Everything about a device can be changed afterwards on its own form — the scan is a way to avoid typing forty addresses, not a commitment to how they are configured. The Getting Started page covers what the device fields mean and which connection method to choose.

The activity log

The Activity page is the audit trail. Each row records the time, the user and their role, the source address, the user agent, what was done, to which resource, whether it succeeded, and the HTTP status behind that verdict.

Behind a reverse proxy on the same host or local network, the source address is the client address the proxy passes on, not one the client could write into a header itself. A request that reaches the manager straight from a public address is recorded with that address. (v1.106.0+)

What lands there is a fixed list, not everything that moves. It covers the changes worth answering for later: users, sites and devices, including Wi-Fi passwords and LTE modem firmware; commands, template runs and script deploys; upgrades, upgrade schedules and queue presets; backups and backup schedules; webhooks; log alert rules; DNS records, their import from a router and DNS sync settings and runs; templates; licence activation; scans, clearing a list of found devices and discovery profiles; settings; clearing the syslog; the CVE refresh; auto-block and whitelist changes; passkey registration and removal; and API key management. A few reads are in the list too, because reading them matters — viewing the user list, downloading a backup, exporting devices as a portable bundle.

Signing in is recorded as well, and so is failing to: a sign-in, a sign-in refused on the password, a second factor refused. The changes a person makes to their own account are in the list on the same footing as an administrator's — password, two-factor authentication, backup codes. Signing out is not recorded: it happens in the browser, and the server has nothing to see.

Failures are kept alongside successes, and a refusal counts as one: an action turned away for insufficient rights is stored as a failed row with the status that produced the verdict. It is the attempt that is audited, not only the change.

Values that should not be written down are masked before the row is stored: passwords and passphrases, tokens, secrets, private keys, API and licence keys, webhook secrets, two-factor backup codes, and SNMP community strings (v1.94.0+). Masking works on the name a value arrives under, so what that list names is what it covers, and it applies as a row is written rather than as it is read — so what a row holds is decided by the version that wrote it.

Starting an upgrade is recorded when it is accepted, which says nothing yet about how it went. So an upgrade run and an upgrade queue each write a second row when they finish, with how many devices succeeded, failed or were skipped, and why a safety stop ended it if one did. That includes queues started by a schedule, which have no user behind them. (v1.88.0+) A bulk change of update channel closes itself the same way. (v1.91.1+)

Resource names are resolved as the row is written, not when you read it — a device row keeps the name and host it had at the time, so the trail stays legible after a rename or a deletion.

Reading it

Administrators see every row and can filter by user, among everyone who appears in the log, including accounts since deleted; everyone else sees their own actions only, and that restriction is applied server-side rather than in the browser. Filters cover the action, the resource type and identifier, the result, a free-text search and a date range, and apply as you change them. The current filter exports as CSV, up to ten thousand rows.

An administrator limited to certain sites sees a narrower trail: rows about devices and sites they can open, plus rows that belong to no site at all, such as sign-ins and settings changes. The CSV export follows the same rule, so it cannot be used to read past it. A row whose device has since been deleted can no longer be attributed to a site, and those are hidden from a scoped administrator rather than shown. (v1.94.0+)

For administrators the page also tails live over the WebSocket, so an action taken elsewhere appears without a refresh. The channel that carries it refuses non-administrator subscriptions outright.

Rows are pruned daily, ninety days by default. Shortening the retention runs a prune there and then rather than waiting for the next daily pass.

Task History

The activity log says who started something. System → Task History says how it went, device by device (v1.100.0+). It lists the background operations the server records, newest first: upgrades started from the buttons, upgrade queues including scheduled ones, update checks, channel changes, config exports, scheduled backups and network scans.

Open a row to see each device's result and message, and after an upgrade the versions it came back with. For a device that did not succeed it also shows the step it had reached: checking, installing, rebooting or verifying. Failed devices are listed first. You can filter by type, status and device name, and older entries load a page at a time. Entries written before 1.100.0 carry no step.

Every role has the page, and it follows site scope the same way the Active Tasks tray does: you see only tasks that touched devices you can open, and only those devices inside each task. Entries are kept as long as activity log rows and pruned in the same daily pass.

Settings

The top of the Settings page is personal and available to every role: your password, two-factor authentication and passkeys. The last two are covered on the Users and Access page; the password section is where anyone, of any role, changes their own — and doing so ends every other session that account has open. An operator or a viewer opens this page for those three and sees nothing else on it.

The rest is administrators only. That is the OpenCelliD key, used to resolve LTE cells to approximate coordinates — an install-wide setting rather than a personal one — the shared SSH key, and below them System config. Every value in System config resolves through three layers, in this order:

1. An environment variable, if one is set for that key
2. A value stored in the database, if one was saved from this page
3. The built-in default

Which of the three a value came from is marked on its row, and that is the part worth understanding. A value coming from the environment is marked from env and its control is disabled; the API refuses to change it as well, so the lock is real rather than cosmetic. Every row carries the name of its environment variable beside the label, which is the name to remove: take the variable out of your environment and restart the container to manage that setting from the interface. A value that came from the database offers Reset to default instead, and one still sitting at its built-in default carries neither mark.

Settings marked as secrets — the NVD API key, the Prometheus scrape token — are encrypted at rest and never returned by the API. The field tells you whether a value exists; it never shows it. Clearing one falls back to empty.

Every setting on this page applies at runtime — none of the 55 needs a restart. Changing the CVE interval rebuilds its timer, switching the feed off stops it there and then, and the auto-block thresholds apply to the next signal that arrives. Taking effect immediately is not the same as being harmless, mind: changing the WebAuthn relying-party identity takes effect at once and invalidates every passkey already registered, which is why that field says so in its own hint.

When a configuration key is renamed, the old environment variable keeps working as an alias, so an existing .env does not break on upgrade. If both names are set, the current one wins.

Shared SSH key

One SSH key for every device, instead of a password or a pasted key on each one (v1.108.0+). Generate key makes an ed25519 pair; Use my own key… takes a private key you already have, RSA or ed25519, without a passphrase. Only the public half and its fingerprint are ever shown again. Administrators see the card; creating, replacing or removing the key takes an administrator with no site limit.

Put on devices… adds the public key to the RouterOS user of each device you pick, logs in with the key to check it works, and only then switches the device to Shared key. If the check fails, the key it just added is taken off again and the device keeps its old login. A device that already accepts the key is simply switched over. Bear in mind that once a RouterOS user has a key, SSH stops accepting that user's password.

While any device logs in with the key, it can't be replaced or removed: move those devices to another login first. A device bundle exported for another install says the device used the shared key, but never carries the key itself.

What is configurable

System config is grouped, and the sub-navigation on the left of the page follows those groups. What each one covers:

The full list of environment variables, including the ones set at install time and never exposed here, is on the Installation page.