RouterOS Containers: Run Docker on MikroTik

Summary MikroTik RouterOS v7 can run Docker-compatible containers directly on the router, so DNS filtering, monitoring agents, and small network services live next to the routing plane instead of on a separate box. This guide covers the hardware and architecture requirements, enabling container device-mode safely, building veth and bridge networking with NAT, deploying your first container, and managing containers across a fleet. RouterOS 7.23 (May 2026) expanded the catalog of ready-to-run container apps, making this a practical option for ISPs and lab builders alike.

What Are Containers on MikroTik RouterOS?

Containers on MikroTik RouterOS are MikroTik’s implementation of Linux containers that lets a RouterOS v7 device run isolated, Docker-compatible application images directly on the router. They work with images from Docker Hub, GCR, Quay, and other registries, and although RouterOS uses its own CLI syntax instead of the docker command, the underlying behavior is the same — pull an image, give it a network, mount storage, and run it. (MikroTik documentation)

For an ISP or a lab, this means small network-adjacent services can be co-located with the routing plane: a Pi-hole or AdGuard DNS filter, a monitoring agent, a reverse proxy, or an IoT bridge. The RouterOS 7.23 stable release on 25 May 2026 added a long list of ready-to-run apps — including paperless-ngx, nextcloud, lorawan-stack, birdnet-go, and Docker-management front-ends like portainer and dockge — alongside a new network-outgoing-access switch to block a container from initiating outbound traffic. (RouterOS 7.23 changelog)

Requirements and Hardware

The container package is compatible with arm, arm64, and x86 architectures, and it must be installed before anything else. Pulling a remote image needs a lot of free space, so MikroTik recommends external storage rather than the device’s internal flash. (MikroTik documentation)

Plan for external media on USB, SATA, or NVMe, formatted with a filesystem RouterOS supports. MikroTik suggests a disk capable of at least 100 MB/s sequential throughput and 10K random IOPS — slower disks make image extraction painfully long. Avoid placing container volumes on built-in storage, which is small and wears out under container write patterns. Devices with very limited flash should use pre-built images on the attached disk instead of pulling remotely.

Enable Container Device-Mode Safely

Containers are disabled by default and, for good reason, require physical access to switch on. Enable the feature with:

/system/device-mode/update container=yes

RouterOS then waits for you to confirm with a press of the reset button or a cold reboot. This physical-confirmation gate is a deliberate security control: once container mode is on, containers can be added, started, and removed remotely, and a malicious image can become a foothold on the router. MikroTik is blunt about this — if your RouterOS device is compromised, containers make it trivial to install malicious software, and there is no security guarantee for third-party images.

Treat the router hosting containers as exactly as secure as the least-trusted image you run on it. Only deploy images you trust, keep the device firewalled, and review our device-mode security operations guide before enabling this in production.

Build the Container Network

Containers need a virtual interface, a bridge, and NAT to reach the internet. The pattern below mirrors “bridge” networking in Docker. First create a veth interface and a bridge that shares its gateway address:

/interface/veth/add name=veth1 address=172.17.0.2/24 gateway=172.17.0.1
/interface/bridge/add name=containers
/ip/address/add address=172.17.0.1/24 interface=containers
/interface/bridge/port add bridge=containers interface=veth1

One veth can serve many containers, and creating additional veth/bridge pairs lets you isolate groups of containers from each other. If you are new to RouterOS bridging, our bridge configuration tutorial explains the underlying model. Next, add a masquerade rule so outbound container traffic is translated — see the NAT configuration guide for the full picture:

/ip/firewall/nat/add chain=srcnat action=masquerade src-address=172.17.0.0/24

Deploy Your First Container

Point the registry and the temporary extraction directory at your external disk, then add the image. The Pi-hole example below is the canonical one from MikroTik’s documentation:

/container/config/set registry-url=https://registry-1.docker.io tmpdir=disk1/tmp
/container/add remote-image=pihole/pihole interface=veth1 root-dir=disk1/images/pihole name=pihole logging=yes

Adding the container starts the download and extraction but does not run it. Check progress with /container/print and wait until status=stopped, then start it:

/container/start pihole

Finally, publish the service by forwarding a port from the router to the veth address:

/ip firewall nat add action=dst-nat chain=dstnat dst-address=192.168.88.1 dst-port=80 protocol=tcp to-addresses=172.17.0.2 to-ports=80

Pi-hole now answers on the router’s LAN IP. Running DNS filtering this way is an alternative to RouterOS’s native blocklists — if you prefer the no-container route, see our RouterOS adlist tutorial.

Manage Containers Across a Fleet

A single container on one router is easy. The real operational question for an ISP is consistency: the same image, the same veth and NAT scheme, the same storage layout, and the same start-on-boot and memory limits on every device. RouterOS gives you the primitives — start-on-boot=yes survives reboots, and memory-high or memory-max cap RAM per container so a runaway service cannot starve the routing plane:

/container/config/set memory-high=200M
/container/set pihole start-on-boot=yes

The hard part is doing this identically across dozens or hundreds of remote routers, then proving each one actually came back up after a reboot — especially when the device sits behind CGNAT and you cannot simply reach its public IP.

Tips

• Keep every container volume on the external disk; never on internal NAND.
• Use a separate veth/bridge pair to isolate untrusted containers from trusted ones.
• Set memory-max on anything you don’t fully trust to keep the router responsive.
• For a clean test bed before touching production, run the same images on a virtualized CHR instance before deploying to physical routers.

Take the Next Step

Containers turn a MikroTik router into a tiny application host, but a fleet of those hosts needs orchestration. MKController templates RouterOS configuration centrally, applies it to every device in your inventory, and tracks drift so you can see which router diverged — and through NATCloud it reaches devices behind CGNAT to confirm a container restarted after maintenance. That closes the gap between configuring one container by hand and operating them reliably across an entire ISP network.

Start your free MKController trial