Three screens an administrator uses and everyone else can mostly ignore: finding routers on a range, reading back who did what, and changing how the manager behaves.
The Scan Network page sweeps an address range for MikroTik devices. It is an administrator action, and it takes one set of credentials for the whole range.
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. Anything over 65 534 hosts is refused rather than attempted.
Each address goes through two stages. First a plain TCP connection 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 the three answers is reported as unreachable and probed no further.
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.
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. Addresses already registered as devices are marked as such in the results, so you cannot add them twice by accident.
Tick the rows you want, choose a site from the dropdown, and Add Selected registers them. 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, and the credentials used for the scan become the device's stored credentials.
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 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.
What lands there is a fixed list, not everything that moves. It covers the changes worth answering for later: users, sites and devices; commands; upgrades and the upgrade queue; backups and backup schedules; webhooks; templates; licence activation; scans; settings; 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.
Values that should not be written down are masked before the row is stored: passwords, tokens, secrets, private keys, API and licence keys, webhook secrets, two-factor backup codes. A recorded request body never carries a credential.
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.
Administrators see every row and can filter by user; 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. The current filter exports as CSV, up to ten thousand rows.
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.
The Settings page has two halves. The top is personal and available to everyone: two-factor authentication, passkeys, and the OpenCelliD key used to resolve LTE cells to approximate coordinates. Two-factor and passkeys are covered on the Users and Access page.
Below that is System config, which administrators get and other roles do not. Every value there resolves through three layers, in this order:
The page shows which of the three each value came from, 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. To manage such a setting from the interface, remove the variable from your environment and restart the container. A value that came from the database offers "Reset to default" instead.
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 49 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.
System config is grouped, and the sub-navigation on the left of the page follows those groups. What each one covers:
| Group | Covers |
|---|---|
| CVE feed | The daily NVD fetch, its interval (24 hours by default) and an optional NVD API key |
| Activity log | Audit retention, 90 days by default |
| Monitoring | The default poll interval (60 seconds), how many devices are polled at once (10), and whether routine polling uses SNMP instead of SSH |
| Traffic history | Three retention windows: one-minute interface samples (7 days), BGP samples and device metric samples (90 days each) |
| LTE data usage | The monthly transfer counter and how close to a device's limit the warning fires |
| Metric alerts | Fleet-wide CPU, memory and temperature thresholds that fire a webhook; a device can override them — see Metric thresholds |
| Prometheus export | The /metrics endpoint, off by default, with an optional scrape token |
| Syslog | Receiver retention and cleanup — see the Logs page |
| Default backup policy | The fallback schedule for sites with none of their own — see Backups |
| Schedulers | How often the backup and upgrade schedulers wake up to look for due work |
| External export | Mirroring configuration exports to a host-mounted volume |
| Authentication | Access and refresh token lifetimes |
| WebAuthn / Passkeys | The relying-party identity and allowed origins. Changing them breaks existing passkeys |
| Logging | Console verbosity |
| Defaults | Pre-filled values for new devices, including the SSH and API ports the scan form also reads |
| MCP endpoint | The read-only MCP server, off by default. It answers questions about the fleet within the permissions of the API key used, and never writes to a device |
| Auto-block / IDS | Thresholds, window, block duration and the address-list name — see the Security page |
The full list of environment variables, including the ones set at install time and never exposed here, is on the Installation page.