Getting Started

1. First login

The first administrator is created by the seed command from the installation guide:

docker exec mikr-manager node scripts/seed.js

It creates the user admin with the password admin and the superadmin role. It only runs when the database has no users at all — running it again later prints a message and changes nothing, so it cannot reset a password you have already set.

Open the manager on port 3000 and log in with those credentials.

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 sit in an unnamed group.

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. Commands, upgrades, backups and configuration changes do not.

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.

What an SNMP-only device gives you

Choose SNMP when SSH and REST are not available or not wanted on a box. 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.

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 budget is only worth setting on a switch running from a non-standard power supply: left empty, a PoE switch takes its budget from the model's datasheet figures.

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, and the devices page can import a list. Get the first one right by hand first — the same credentials mistake repeated across thirty devices is no fun to undo.

6. 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.

7. 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.
• 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.