While working with ZeroTier on RouterOS I kept running into the same architectural question: how should a management interface represent the relationship between a MikroTik router, its ZeroTier instances, the networks joined by those instances, and the Network Controllers they may host?
That question eventually became ZT Control Plane, an independent open-source project:
I would like to show how I have mapped the RouterOS model and ask the MikroTik community whether anything important is still represented incorrectly or missing.
How the RouterOS model is represented
The application does not treat one RouterOS connection as one flat "ZeroTier controller."
A RouterOS connection represents the physical or virtual router. Inside it, the application discovers each item from: /zerotier/instance
as an independently manageable ZeroTier runtime.
An instance name does not have to be zt1, and a router may contain multiple instances. Each instance can have several roles:
- Node — it has joined one or more external ZeroTier networks;
- Network Controller — it hosts networks under
/zerotier/controller; - Node + Network Controller — it performs both roles;
- Runtime only — the instance exists but currently has no joined or hosted networks.
This distinction matters because the following objects belong to different parts of RouterOS:
| RouterOS object | Meaning in the interface |
|---|---|
/zerotier/instance |
Local ZeroTier runtime and identity |
/zerotier |
Network interfaces joined by an instance |
/zerotier/controller |
Networks hosted by an instance's Network Controller |
/zerotier/controller/member |
Members registered in those controller networks |
/zerotier/peer |
Peers observed by a particular instance |
All values in the screenshot come from a fabricated demo environment.
What can currently be managed
Through the RouterOS REST API, the current implementation can discover and manage:
ZeroTier instances
- multiple independently named instances;
- enabled/disabled state;
- name and comment;
- UDP port;
- RouterOS discovery interfaces;
- route distance;
- runtime state and public identity where RouterOS exposes them.
Joined ZeroTier networks
- join and leave operations;
- interface name and comment;
- enabled/disabled state;
- the owning ZeroTier instance;
- VRF and ARP timeout;
allow-managed,allow-default, andallow-globalpolicies;- assigned addresses and runtime status where available.
RouterOS-hosted Network Controllers
- list, create, update, enable/disable, and remove controller networks;
- private/public network mode;
- IPv4 assignment range and managed routes supported by RouterOS;
- list, add, update, authorize/deauthorize, enable/disable, and remove members;
- member name, comment, bridge, IP address, and ZeroTier address.
Peers and diagnostics
- peer identity and role;
- latency;
- active path information;
- the instance through which the peer was observed.
The interface intentionally does not display controls copied from ZeroTier Central when RouterOS has no equivalent operation.
Why this is part of a larger control plane
The original goal was only to make RouterOS ZeroTier management easier to inspect. In practice, many environments also contain a self-hosted ZeroTier One controller or a Central account.
ZT Control Plane can therefore register RouterOS alongside:
- self-hosted ZeroTier One Network Controllers;
- New ZeroTier Central;
- Legacy ZeroTier Central.
The global network and node inventories can search across those providers, but every result retains its owning controller. An operation is always sent back to the provider that owns the object.
The project separates Network Controllers from managed endpoints. A member record visible through Central, for example, does not imply that Central can configure the ZeroTier client behind that member. A RouterOS connection is different because its REST API can expose both locally joined networks and locally hosted controller networks.
Deployment and security
The standard deployment is one unprivileged Docker container containing the web application, API, and SQLite database. It does not install ZeroTier One and does not need a TUN device or elevated network capabilities.
RouterOS credentials are encrypted before being stored. TLS certificate verification is enabled by default and can be disabled only as an explicit per-connection choice for isolated test environments.
The application also provides users and roles, TOTP two-factor authentication, an audit log, IP access rules, and backup/restore for its own configuration database.
Feedback I am looking for
I would especially appreciate feedback from people using more complex RouterOS ZeroTier configurations:
- Does the mapping between router, instance, joined interface, controller network, member, and peer match your operational model?
- Are there important editable properties from
/zerotier,/zerotier/instance,/zerotier/controller, or/zerotier/controller/memberthat are missing? - Is anyone running several ZeroTier instances with different node/controller roles on the same router?
- Which RouterOS-specific safety checks should be added before changing or removing an object?
- Which diagnostics would be most useful when a joined network or controller member is not working as expected?
The source, deployment instructions, architecture notes, screenshots, and capability matrix are available here:
The interface gallery is here:
The project is licensed under Apache License 2.0. Issues and focused pull requests are welcome, but practical RouterOS feedback is just as valuable at this stage.
ZT Control Plane is an independent community project. It is not affiliated with, sponsored by, or endorsed by MikroTik or ZeroTier, Inc. MikroTik, RouterOS, and ZeroTier are trademarks of their respective owners.