MikroTik Containers: How to Run Docker on RouterOS v7

Running Docker containers on a MikroTik router used to mean adding a Raspberry Pi or a small Linux box next to your rack. RouterOS v7 changed that. You can now deploy pihole, Cloudflare Tunnel, monitoring exporters, and other lightweight Linux services directly on the router itself, using container images from Docker Hub, GCR, or Quay.

This works because MikroTik built a minimal container runtime into RouterOS v7. It is not the full Docker Engine, and it does not replace a real Linux container host for heavy workloads. What it does well is co-locate small network-adjacent services with the routing plane: DNS filtering, vpn clients, reverse proxies, and IoT bridges, all running on the same hardware that already handles your routing, firewall, and wi-fi.

The catch is that not every MikroTik device supports containers, internal flash storage is not enough, and the configuration is more manual than docker run. Done correctly, a MikroTik router becomes a dual-purpose edge platform. Done carelessly, you wear out the NAND, expose your LAN, or destabilize routing.

This guide covers which MikroTik routers support containers, the storage and memory you actually need, how to enable container mode in RouterOS v7, container networking with veth and bridges, the new /app system introduced in v7.22, and practical deployments of pihole and Cloudflare Tunnel on an RB5009.

Key Takeaways

• RouterOS v7 lets you run Docker-compatible containers directly on supported MikroTik routers, turning the router into a small edge compute platform.
• Container mode requires physical confirmation at the device and external storage on USB, SATA, or NVMe. The internal NAND on most MikroTik devices is too small and wears out quickly.
• MikroTik supports containers on ARM, ARM64, and x86 hardware. Common MikroTik devices for this use case include the hAP ax³, RB5009, CCR2004 series, and CCR2116.
• RouterOS v7.22 added an /app system with compose YAML manifests, lifecycle automation, and a curated catalog on top of the raw /container engine.
• Treat MikroTik containers as code running inside your firewall. Pin image versions, isolate them on a dedicated VLAN or bridge, and apply ip/firewall rules to limit blast radius.

When Running a MikroTik Container Makes Sense

A MikroTik router is a good container host when the workload is network-adjacent and lightweight: DNS filtering, monitoring exporters, VPN clients, small reverse proxies. These services benefit from sitting next to the routing plane.

It is a poor host for anything CPU-heavy or storage-heavy. Media servers, databases, and CI runners belong on a Raspberry Pi 5, an Intel N100 mini-PC, or a proper server. The router should never become the bottleneck for the network it serves.

Simple test: if the service is down for an hour, does your network still work? If yes, it is a fine container candidate. If no, run it on dedicated hardware.

What MikroTik Containers Are (and What They Are Not)

MikroTik's container feature is a minimal Linux container runtime built into RouterOS v7. It runs containerized environments compatible with images from Docker Hub, GCR, Quay, and other providers that use the same formats. It is not the Docker Engine, and it does not ship a Docker CLI or Kubernetes.

The runtime supports namespace isolation, env variables, mount points, port mapping, and remote-image pulls. It does not provide orchestration, autoscaling, image vulnerability scanning, or centralized logging. You manage everything through the /container and /app CLI hierarchies in RouterOS.

How RouterOS Containers Differ from Docker

There is no docker run shortcut, no automatic DNS for service names, and no built-in NAT setup. You define a veth interface, attach it to a bridge, assign an IP, and write the NAT rule yourself. This is manual compared to Docker and natural to a network engineer.

The benefit is precise control. Container traffic is just another interface to RouterOS, so ip/firewall rules, queues, mangle marks, and VLAN tags work exactly as they do on any other RouterOS interface.

Which MikroTik Routers Support Containers?

Container support requires an ARM, ARM64, or x86 CPU. The container package is compatible with arm, arm64, and x86 architectures. MIPS-based MikroTik devices like the original hEX and hAP lite cannot run containers.

There is one nuance for the hEX S Refresh For devices with the EN7562CT CPU like the hEX Refresh, only arm32v5 container images are supported, meaning a limited number of containers can be run. Most modern Docker Hub images do not publish arm32v5 tags, so plan accordingly.

Supported MikroTik Devices at a Glance

Storage and Memory Requirements

The internal NAND on most MikroTik devices (1 GB on RB5009, 128 MB on CCR2004) is not designed for the write patterns containers generate. Image layers, logs, and persistent data will exhaust flash space quickly and wear out the NAND.

Use a USB 3.0 drive at minimum. An external disk supporting at least 100MB/s sequential read/write speed and 10K random IOPS is recommended. With slower disks, container extraction times become longer. A small SSD in a USB 3.0 enclosure is the sweet spot for RB5009 and above. The RB5009 has no native M.2 slot, so storage is USB-attached.

What Changed in RouterOS v7.22: App Management and Compose YAML

Container support originally landed in RouterOS 7.4beta and required manual /container/add, /interface/veth/add, mounts, and ip/firewall rules. Starting v7.22, users can create apps themselves by writing a compose YAML file within RouterOS.

The new /app system layers a curated catalog and compose-style YAML on top of /container. Each app can consist of one or multiple pre-configured containers, and the necessary RouterOS configuration such as firewall rules and address translation will be applied automatically. The catalog is prepared by MikroTik, but the images get sourced from registries such as Docker Hub, GCR, and Quay.

A minimal custom app YAML for an alpine-based iperf3 server:

yaml

name: alpine-iperf descr: Alpine Linux container running iperf3 server
category: network default-credentials: none services: iperf: image: 
docker.io/networkstatic/iperf3 ports: - 5201:5201

Load it on the router:

/app add yaml=[/file get alpine-iperf.yml contents]

The /app system inherits the same hardware requirements as /container and still needs external storage.

How to Enable Container Mode on RouterOS v7

The container package is part of the extra packages bundle. A RouterOS device with v7.4beta or later, the container package installed, physical access to the device, and an attached HDD, SSD, or USB drive with a supported filesystem are required.

routeros

# Verify the container package is present /system/package/print # Enable container mode (requires physical confirmation) /system/device-mode/update container=yes # Reboot /system/reboot

You must confirm the device-mode change with a press of the reset button, or a cold reboot for x86. Device-mode limits container use by default. Before granting container mode access, make sure your device is fully secured. The five-minute confirmation window is deliberate. Using a root shell, someone may leave a permanent backdoor or vulnerability in your RouterOS system even after the container is removed, so the physical step is your last line of defense against unattended activation.

After confirmation, verify:

routeros

/container/print

Container Networking with Veth, Bridges, and NAT

Container networking on RouterOS uses a virtual interface/veth attached to a bridge. The configuration is equivalent to "bridge" networking mode in other container engines such as Docker.

routeros

# Dedicated bridge for containers /interface/bridge/add name=containers # 
Gateway IP on the bridge /ip/address/add address=172.17.0.1/24 
interface=containers # veth pair the container will use /interface/veth/add 
name=veth1 address=172.17.0.2/24 gateway=172.17.0.1 # Attach veth to the 
bridge /interface/bridge/port/add bridge=containers interface=veth1 # 
Source NAT so the container can reach the internet /ip/firewall/nat/add chain=srcnat src-address=172.17.0.0/24 \ action=masquerade out-interface-list=WAN

Pick a subnet that does not overlap LAN, VPN, or tunnel ranges. For tighter isolation, put the container bridge on its own VLAN and write filter rules between the VLAN and the rest of the network. Containers on the same bridge can reach each other directly, which is usually what you want for a pihole + web UI pair but not for unrelated workloads.

Pulling Images and Handling ARM64 Architecture Mismatches

The most common failure mode is pulling an x86 image onto an ARM64 router. The container starts and immediately exits with an exec format error.

Most popular images publish multi-arch manifests and the runtime selects ARM64 automatically. If the image is single-arch x86, either find an ARM64 fork or build your own using docker buildx --platform linux/arm64, then upload the tar to the router:

routeros:

/container/add file=disk1/pihole-arm64.tar interface=veth1 root-dir=disk1/pihole

This is also the right workflow for air-gapped routers and reproducible pinned deployments.

How to Deploy Pi-hole on a MikroTik Router

Pi-hole is the canonical first container for MikroTik. It exercises the full networking and storage path and provides DNS-level ad-blocking for the whole LAN.

routeros

# Mount points for persistent Pi-hole data
/container/mounts/add name=pihole-data src=/disk1/pihole dst=/etc/pihole
/container/mounts/add name=pihole-dnsmasq src=/disk1/dnsmasq dst=/etc/dnsmasq.d

# Add the container
/container/add remote-image=pihole/pihole:latest \
  interface=veth1 \
   root-dir=disk1/pihole \
  envlist=pihole-env \
   mounts=pihole-data,pihole-dnsmasq \
  start-on-boot=yes

# Start it
/container/start [find tag~"pihole"]

Point DHCP at the container so clients use pihole for DNS:

/ip/dhcp-server/network/set [find] dns-server=172.17.0.2

On an RB5009, pihole typically idles at ~3% CPU and 80–120 MB RAM after the web UI loads. Cached query response is sub-millisecond. Lock the pihole web UI to your management network with ip/firewall filter rules.

How to Run Cloudflare Tunnel in a MikroTik Container

Cloudflare Tunnel exposes internal services to the public internet through Cloudflare's network without any inbound port-forwarding (dstnat). The daemon is tiny and outbound-only, which fits a router-hosted container well.

/interface/veth/add name=veth-cf address=172.17.0.3/24 gateway=172.17.0.1
/interface/bridge/port/add bridge=containers interface=veth-cf
 
/container/envs/add name=cf-env key=TUNNEL_TOKEN value=YOUR_TOKEN_HERE
 
/container/add remote-image=cloudflare/cloudflared:latest \
  interface=veth-cf \
   root-dir=disk1/cloudflared \
  envlist=cf-env \
  cmd="tunnel --no-autoupdate run" \
  start-on-boot=yes
 
/container/start [find tag~"cloudflared"]

Configure routes in the Cloudflare Zero Trust dashboard to point at internal IPs. The container needs only outbound HTTPS to Cloudflare, so firewall rules can be tight.

Security Considerations

A container on your router is code with network access running on the device that defines your network's security boundary. Pin image tags to specific versions, never :latest in production. Pull only from registries you trust, and review the Dockerfile when source is available.

Apply ip/firewall filter rules to the container bridge. By default, containers can reach the LAN. Restrict the container subnet to only the destinations it actually needs: DNS upstreams for pihole, Cloudflare endpoints for cloudflared, and nothing else inbound to the LAN. RouterOS containers run in Linux namespaces but lack the defense-in-depth of a hardened Docker host with seccomp or AppArmor profiles, so design firewall rules assuming compromise.

Logging, Monitoring, and Backups

Enable logging at container creation with logging=yes, then view with /log/print where topics~"container" and /container/print detail. There is no docker stats equivalent, so for sustained monitoring run a small Telegraf or node-exporter container on the same bridge and scrape it from Prometheus elsewhere on the network.

Container configuration is in /exportand standard config backups. Images and mounted data on external storage are not. Back up the contents of /disk1 separately, typically via scheduled rsync to a NAS from a different machine. To update an image, stop and remove the container, then re-add it pointing at the same root-dir and mounts so persistent data survives.