MikroTik Solutions

Changes To Container Limitations
Login

Changes To Container Limitations

Changes to "Container Limitations" between 2026-01-20 19:01:05 and 2026-01-30 06:49:11

306
307
308
309
310
311
312

313
314
315
316
317
318
319
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320







+








### <a id="armv5"></a>ARMv5

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 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].

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!_