In brief, the reason MikroTik doesn’t ship `container.npk` for 32-bit PPC, 32-bit MIPS, and TILE is that there are few Linux distro images in OCI format to use as base images, and it isn’t greatly in their interest to pull that together along with the QEMU and `binfmt_misc` pieces for you, nor is it in the financial interest of Docker, Podman, etc.

There’s nothing stopping anyone reading this that has the skill and motivation to do this from doing so, but you’ll have to prove out your containers under emulation. Not until then do I see MikroTik being forced to take notice and provide a build of `container.npk` for that platform. It’s not quite a classic chicken-and-egg situation, but I can’t ignore the hiss of radio silence I got in response to [this challenge](https://forum.mikrotik.com/viewtopic.php?t=204868#p1058351) on the forum.

Until someone breaks this logjam, it’s fair enough to say that RouterOS’s container runner only supports ARM and Intel CPUs.

Incidentally, exploration of the binfmts available to you on your container build host of choice might result in output like `linux/mips64le`, leaving you exulting, “See, there _is_ MIPS support!” But no. First off, this is 64-bit MIPS, while all MIPS CPUs shipped by MikroTik to this date have been 32-bit. Second, it’s [little-endian](https://en.wikipedia.org/wiki/Endianness) (LE) which means it wouldn’t work with the big-endian MIPS CPUs that were more popular historically. Third, even if you find/build a platform that includes support for the MIPSBE, MMIPS, and SMIPS CPU types MikroTik shipped, you’re likely back to lack of a base OS to build from.


## <a id="armv5"></a>…And Only _Most_ ARM at That

There's a special case to be aware of here: the [2024 hEX Refresh](https://mikrotik.com/product/hex_2024) will run `container.npk`, but because the EN7562 SoC it is based on is limited to the ARMv5 instruction set, there are [nearly zero][^v5img] available container images available. For perspective, the Raspberry Pi foundation selected a chip using the ARMv6 architecture for their initial product offering in 2012, then switched to the ARMv7 architecture for the Pi 2 and newer.

This is _seriously old tech!_

That is not to say it is impossible to build container images for this device, but that you're in much the same situation as for the non-ARM CPU types above.

[^v5img]: As of this writing, an [architecture search for "armv5" on Docker Hub](https://hub.docker.com/search?architecture=armv5) returns zero results, but in the past, it returned a small number, approximately five, as I recall. None were for mainstream Linux distros, the type most useful as an image base.



# <a id="auto"></a>Automation

Included in the list of lacks [above](#global) is the [Docker Engine API][DEAPI]. The closest extant feature is the [RouterOS REST API][ROAPI], which can issue commands equivalent to those available at the CLI via `/container`. With this, you can programmatically add, remove, start, and stop containers, plus more.

What RouterOS does _not_ offer is a way for common control plane software like Docker Desktop or [Portainer](https://www.portainer.io/) to manage the containers running on your routers. This is because these programs were written with the assumption that everyone’s running Docker or Podman underneath, and as long as they stick to a compatible subset of the Docker Engine API, implementation details cease to matter up at these programs’ level of abstraction.