There’s a special case to be aware of here: MikroTik have released a few products now based on the EN7562 SoC, which includes a low-spec ARMv5 core:

*   [2024 hEX Refresh](https://mikrotik.com/product/hex_2024)
*   [2025 hEX S Refresh](https://mikrotik.com/product/hex_s_2025)
*   [2026 hAP ax S](https://mikrotik.com/product/hap_ax_s)

These are billed as “ARM32” but that term encompasses [many versions and variants](https://en.wikipedia.org/wiki/ARM_architecture_family#32-bit_architecture) which aren’t all compatible.(^They aren’t even strictly upward-compatible. A container built for an ARMv6 processor with a hardware floating-point unit won’t run on an ARMv7 with software FP, for instance.) 
These will run `container.npk`, but because there are [nearly zero][^v5img] container images available to serve as a base, your options will be strongly constrained unless you're willing to do the work of porting containers yourself. Fortunately, unlike with the legacy CPU types mentioned above, [there do exist a good number of base container images][arm32v5] to get started with. The most broadly useful is [their `debian` image][v5deb].

While these RouterOS devices will all run `container.npk`, there are [nearly zero][^v5img] container images available to serve as a base. Consequently, your options for runnable containers will be strongly constrained unless you're willing to do the work of porting containers yourself.

Fortunately, unlike with the legacy CPU types mentioned above, [there do exist a good number of base container images][arm32v5] to get started with. The most broadly useful is [their `debian` image][v5deb].

The general points above remain true: if you start with a container that does something _other_ than `FROM debian:…` in its `Dockerfile`, changing that line to refer instead to `arm32v5:debian` and rebuilding is unlikely to work. You're in for a manual porting effort.

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 3, then ARMv8 (a.k.a. aarch64 or ARM64) for the Pi 4 and 5. ARMv5 is _seriously old tech!_

[^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.