In short: a container on RouterOS is a way to run a packaged Linux program — a DNS resolver, a proxy, a small server — inside the router, isolated from the rest of the system. It is not a virtual machine, and it isn’t a “system” container like Proxmox’s either: RouterOS runs Docker (OCI) images, sharing its own kernel. In this card we line up the three things that confuse people most: what they really are, which devices can run them (it depends on the CPU), and why they stay off until you unlock them with a physical confirmation.

Containers in one line

A container does not carry a whole operating system: it uses the kernel of the device hosting it and adds only the program’s files. The kernel keeps it separate with two mechanisms of the underlying Linux: namespaces (decide what it sees — which processes, which interfaces, which files) and cgroups (decide how much it can use — CPU, memory). It’s lightweight precisely because there is a single kernel, the router’s. What a container can actually see of the router — and how much changes if you start it privileged — we show at the packet level in the howto Containers on MikroTik: what they see of the kernel.

It’s not a VM — and not LXC like Proxmox

Three things that look alike but aren’t the same:

  • Virtual machine (e.g. a CHR on a hypervisor): it has its own kernel and emulated hardware. Maximum isolation, maximum weight.
  • System container (LXC), the Proxmox kind: they share the host’s kernel but contain an entire distro userland, with their own init/systemd; you log in and treat them like a lightweight, persistent VM.
  • Application container (Docker/OCI), the RouterOS kind: they share the kernel and contain a single application, packaged in an immutable image. You configure them from outside (environment variables, mounted folders, start command), you don’t “move in”.

So, the answer to the question everyone asks: RouterOS containers are like Docker’s, not like Proxmox’s LXC. One caveat, though: RouterOS does not run the Docker daemon, nor containerd, nor LXC. It has its own minimal engine; it borrows from Docker only the image format and the kernel primitives.

The images are Docker (OCI)

An image is the program’s “package”. On RouterOS you get it in two ways:

  • Pulling it from a registry (Docker Hub and the like): you give the image name and the router fetches it, exactly like a docker pull would.
  • Importing a tar you built elsewhere with docker/podman/buildah and exported: handy when the router must not touch the Internet.

Two rules that save time. First: the image must match the architecture of the router’s CPU (more on that below); on Docker Hub the multi-architecture manifest handles this, but an amd64-only image will never start on an ARM device. Second: a container is immutable and ephemeral — if it writes data inside that you want to keep (configuration, a database), those folders must be mounted outside the image, onto persistent storage on the router, otherwise they vanish when the container restarts.

Which devices run them? It depends on the CPU

Here’s the biggest surprise: not all RouterOS devices can run containers. The deciding factor is the CPU architecture, not the tier or the price.

  • Yes: ARM, ARM64 and x86 (the latter includes the virtual CHR). Here the container package exists.
  • No: the MIPS family (mipsbe, mmips, smips) and the old TILE/PPC. On these the package simply isn’t there.

You check it in one shot, looking at the architecture-name field:

/system resource print
     architecture-name: arm64
              cpu: ARM64
        free-memory: 812.4MiB
       total-memory: 1024.0MiB

If you read arm, arm64 or x86 you’re good; if you read mipsbe/smips/mmips, no. Beyond the CPU, two practical resources matter and are often underestimated:

  • Storage: the image takes megabytes, and many devices have tiny flash memory. You often need external storage (a USB stick, a disk, an NVMe) to hold images and mounted data.
  • Memory: a small container (a DNS resolver) lives on little, but the more you put in the more RAM you need. Check free-memory before overdoing it.

The lock: device-mode

Even when the architecture is right, containers start off. RouterOS protects them with device-mode: the container feature turns on only with a physical confirmation on the device (a button or a power cycle; on a CHR, a reset from the hypervisor). It’s the same lock that covers the sniffer, the bandwidth test and the proxy, and it exists to stop someone who gets in remotely — even with the admin password — from turning the router into an attack base. How to read it and how to change it without locking yourself out is explained in the card Device-mode: the physical lock on dangerous features.

When they make sense

A container is handy when you want a Linux service next to the router without adding a machine: a resolver with ad blocking, a small monitoring agent, a tunnel, a test server. The upside is closeness to the network and low weight; the limit is that you’re still on a device built to route, not to be a server — so pick lightweight images, mount the data that matters outside, and keep an eye on memory and space. For the rest, it’s Linux: whatever runs in a Docker container elsewhere, with an image of the right architecture, runs here too.