# System requirements

> What the panel needs to run, what your routers need to be managed, and the ports that have to be open between them.

Source: https://joinnasnet.com/en/guides/nasnet-panel/system-requirements/
Last updated: 2026-08-17

---

## Overview

Nasnet Panel has two sides to check. The **host** is wherever the container
runs, either a Docker host on your LAN or the MikroTik itself. The **managed
routers** are the RouterOS devices the panel talks to. They have separate
requirements, and the router-hosted install is the stricter of the two.

If you are installing on a server or a desktop, almost anything current will
do: the image is a few megabytes and the binary runs with `GOMAXPROCS=1`. If
you are installing onto the router, read the RAM and `device-mode` lines
carefully, because those are where installs fail.

## Where the panel runs

### Any Docker host

| Requirement | Value |
| ----------- | ----- |
| Container runtime | Docker, or anything that runs an OCI image |
| Architectures | `linux/amd64`, `linux/arm64`, `linux/arm/v7` |
| Image | `ghcr.io/nasnet-community/nasnet-panel:latest` |
| Memory | ~30 MB free is enough; the image is busybox + musl with a compressed binary |
| Network | Must reach your routers on the LAN, so use `--network=host` if it cannot |
| Ports | `80` and `443` inside the container, mapped wherever you like (the docs use `8080`) |

### On the router, inside a RouterOS container

| Requirement | Value |
| ----------- | ----- |
| RouterOS | v7.x |
| Packages | `container` installed and enabled |
| Device mode | `device-mode container` enabled, which needs physical confirmation the first time |
| Board architecture | `arm`, `arm64` or `x86_64` |
| Free RAM | At least 30 MB |
| Storage | External storage mounted; the installer defaults to `disk1/` |

Enabling container `device-mode` for the first time is a deliberate,
hands-on step: RouterOS asks for a short press of the reset/mode button, or a
cold power cycle on boards without one. It cannot be done remotely, so plan the
install for a time when someone can touch the device.

### On the machine you run the installer from

Only relevant if you use `scripts/install.sh` rather than the graphical
installer.

| Requirement | Value |
| ----------- | ----- |
| Shell tools | `bash`, `curl`, `ssh`, `scp`, and `sha256sum` or `shasum` |
| Reachability | The router answering on Winbox `8291` and SSH `22` |

## Supported devices

### Routers the panel can manage

Any MikroTik running **RouterOS v7** or newer, provided at least one of its
management transports is reachable. There is no model whitelist, because the
panel talks to RouterOS itself rather than to a particular board.

| Device class | Supported | Notes |
| ------------ | --------- | ----- |
| MikroTik, RouterOS v7+ | Yes | The panel's target. All features assume v7 semantics. |
| MikroTik, RouterOS v6 | No | The REST API does not exist, and the v6 configuration model differs. |
| CHR and x86 RouterOS | Yes | Treated like any other RouterOS host. |
| Non-MikroTik routers | No | Nothing else speaks the RouterOS API. |

### Boards that can host the panel

Only relevant if you run the panel *on* the router rather than on a server.
The installer detects the board architecture and pulls the matching image.

| Board architecture | Container image | Notes |
| ------------------ | --------------- | ----- |
| `arm` | `linux/arm/v7` | Common on hAP and cAP class boards. |
| `arm64` | `linux/arm64` | hAP ax, Chateau ax, RB5009 and similar. |
| `x86_64` | `linux/amd64` | x86 RouterOS boxes and CHR. |

Whatever the architecture, the board also needs the `container` package,
`device-mode container` enabled, external storage, and at least 30 MB of free
RAM. A board that meets the architecture line but not the RAM line will install
and then fail to stay running.

## What the panel manages

| Requirement | Value |
| ----------- | ----- |
| RouterOS | v7 or newer |
| Transports | REST API, RouterOS API on `8728`/`8729`, SSH, or Telnet |
| Credentials | A RouterOS user with rights for what you intend to change |

The panel tries the REST API first, falls back to the native RouterOS API, then
to SSH or Telnet. You do not have to pick one. You only have to leave at least
one of them enabled and reachable.

## In the browser

The interface is a React single-page app served by the same process as the API,
so it needs a current mainstream browser with JavaScript enabled. There is no
separate frontend to deploy and no other origin to allow.

## Building from source

Only needed if you are developing the panel rather than running it.

| Requirement | Value |
| ----------- | ----- |
| Node.js | 20 or newer |
| Go | 1.26 or newer |
| Dev ports | `3000` for the frontend dev server, `8080` for the backend |

## Troubleshooting

**The container starts and then exits on the router.** Free RAM is the usual
cause. Check `/system/resource/print` and stop other containers before
retrying, because the panel needs its 30 MB to be actually free rather than
merely installed.

**The installer stops at the `device-mode` step.** That is RouterOS asking for
physical confirmation, not a failure. Press the reset/mode button briefly or
power-cycle the router, then run the installer again.

**The panel loads but cannot see any router.** The container is probably on a
bridge network with no route to your LAN. Re-run it with `--network=host`, or
map the panel onto a network that can reach the routers.

## Related

- [Installation](/en/guides/nasnet-panel/install/)
- [Adding a router](/en/guides/nasnet-panel/add-router/)
- [Architecture](/en/guides/nasnet-panel/architecture/)