Getting Started

1. First login

The first administrator is created by the manager itself, on first start — there is no command to run. It is the user admin with the password admin and the superadmin role.

That only happens while the database has no users at all. Once an account exists it is never recreated, so a later restart cannot reset a password you have already set — and an admin you delete stays deleted rather than reappearing on the next start.

Open the manager on port 3000 and log in with those credentials. The first sign-in with the default password opens a Set a new password screen, and nothing else opens until you have chosen one. If you set INITIAL_ADMIN_PASSWORD before the first start, the account gets that password instead and there is nothing to change. (v1.97.0+)

2. Create a site

A site is a group of devices — normally one physical location. Create it before the first device: sites are what the dashboard groups by, and they are also the unit that per-user access is granted on, so a device added to the right site from the start needs no rearranging later.

Go to Sites → Add Site. Only the name is required:

If you only manage one location, still create one site. Devices without a site work, but they collect in a group called Ungrouped at the end of every list, and a user scoped to specific sites cannot see them at all.

3. Create the RouterOS account

Do not point the manager at your admin account. Create a dedicated user on the router with a group that carries only the policies the manager actually uses. On the router:

/user/group/add name=manager-group policy=ssh,reboot,read,write,sensitive,rest-api,policy,!local,!telnet,!ftp,!test,!winbox,!password,!web,!sniff,api,!romon
/user/add name=mikr group=manager-group password=YOUR_PASSWORD

This limits the damage if the manager itself is ever compromised. The negated policies are deliberate — leave them negated unless you know why you need one of them.

Read-only accounts

An account without the write policy is supported and is a reasonable choice if you only want monitoring. The manager detects it: the device card carries a read-only badge, its page notes which account it is, and Test Connection reports it — so you find out when you add the device, rather than when an upgrade or a backup is rejected months later.

Monitoring, interface and neighbour data all work on such an account, and so do read commands and configuration exports, which need no write permission on the router. What the manager refuses outright on a read-only account is a RouterOS or firmware upgrade and a VLAN or bridge change: the router would reject them anyway, and it says so before spending a reboot window on it. Anything else that changes the configuration is rejected by the router itself when it runs.

4. Choose a connection method

Each device is configured with one method. This is the difference between them:

SSH is used for reading even on REST devices

This surprises people, so it is worth stating plainly. Whatever method a device is set to, the manager reads over SSH and only sends writes over the configured method. The reason is a MikroTik behaviour: the REST API creates an entry in /user/active roughly every ten minutes, and those entries are never cleaned up — left alone for long enough they exhaust the router's session slots. An SSH connection creates one session that goes away when it disconnects.

If SSH is not reachable on a REST device, the read falls back to REST, so the device still works. But plan your firewall rules on the assumption that the manager needs SSH to the router.

There is one way to change that, and it is off until you ask for it: a device with an SNMP community can have its routine polling moved to SNMP, either for that device alone or install-wide. Commands, upgrades and the detail tabs still open SSH or REST when you use them. That is the Monitoring transport field in the next step.

What an SNMP-only device gives you

Choose SNMP when SSH and REST are not available or not wanted on a device. Over SNMP the manager reads the RouterOS version, uptime, CPU load, free and total memory, board name and model, serial number, current and upgradeable firmware, temperature, voltage, power consumption, the device identity, the interface list with neighbours, and interface traffic counters.

It cannot run commands, upgrade, or take backups — there is no SNMP for those. An SNMP-only device is a monitoring target, not a managed one.

5. Add your first device

Go to Devices → Add Device. The form is longer than it needs to be for a first device: only the first block matters, the rest has working defaults.

1. Identity. Name and Host / IP are the only required fields. Pick the Site you just created. If that site carries a backup policy, the form offers to put this device on the same schedule; clear the box to keep it off.
2. Connection. Connection Method — SSH, REST API or SNMP Only. API Protocol is HTTPS by default and only applies to REST. SSH Port defaults to 22 and API Port to 443; both defaults can be changed globally under Settings for all new devices, and a per-device value always wins.
3. Credentials. Username is the RouterOS account you created in step 3. Auth method is either a password or an SSH key — choosing the key shows a field for the private key in PEM form. For SNMP Only, the SNMP Community is required instead; the SNMP Port defaults to 161. On SSH and REST devices a community is optional and enables SNMP as an extra source.
4. Everything else can stay as it is. Monitoring transport decides how routine polling runs and defaults to following the global setting; actions and detail tabs still open SSH or REST on demand. Poll interval empty means the system default of 60 seconds, and the minimum you can set is 10. Tags, notes, IDS auto-block, log retention, LTE limits, the PoE budget override and per-device metric thresholds are all optional and easier to decide once the device is reporting. PoE-out supply is worth a moment on a switch or router that feeds powered devices: pick the MikroTik supply it runs on, or type the volts and amps of any other one, and the manager works out the budget from there. Left empty, a PoE switch uses its model's datasheet figures, while a board that delivers at whatever voltage it is fed — hEX PoE among them — has no ceiling until this is filled in. The next section lists every field with its default.
5. Test the connection. Save, then run Test Connection on the device. It performs a real read of the system information, so a success means the credentials, the port and the account's policies are all genuinely working — not just that the host answers.

Once one device works, the bulk paths are worth knowing: Scan discovers devices on an IP range, written either as 192.168.1.0/24 or as 192.168.1.1-254, and the devices page can Import a bundle exported from another install — passphrase-protected, and devices it already has are skipped. Get the first one right by hand first — the same credentials mistake repeated across thirty devices is no fun to undo.

6. Every field on the device form

The walkthrough above gets one device reporting. This is the reference for the rest of them — what each field does, and what happens if you leave it alone. Almost everything is optional, and a field left empty follows a global setting rather than switching something off.

7. Check that it works

The manager polls every device on a schedule; the default is once every 60 seconds. Within about a minute the device should carry a green Online badge and show its RouterOS version, uptime, CPU and memory.

The badge has five states, and telling them apart saves time:

On the device page, expect some sections to be empty. A router with no wireless has no wireless clients, a board with no health sensors reports no temperature, and a CHR has neither. An empty tab usually means the hardware does not have that feature, not that the read failed.

8. Where to go next

In rough order of how much they pay back:

• Backups — schedule configuration exports before you need one.
• Upgrades — check the fleet for RouterOS and firmware updates in one pass.
• Users and access — roles, per-site scope, and a second factor on the login. Worth reading before the second person gets an account.
• Webhooks — send device-down and threshold events to whatever you already watch, held for a few minutes first if a flapping link would otherwise wake someone.
• Topology — the map of what each device sees of the others, once you have more than a couple in a site.
• Metrics — the Prometheus export for long-term graphs, or the Zabbix template if that is what you run.

If something does not look right, Troubleshooting covers what the symptoms actually mean.