*   USB device entries under `/dev` are on the wish list, but not currently available.(^Not unless RouterOS itself sees the USB device, as with storage media, which you can bind-mount into the container with “`/container/add mounts=…`”.)
    *   There is no GPU support, not even for bare-metal x86 installs.

Lack of a management daemon(^`containerd` in modern setups, `dockerd` in old ones) is not in that list because a good bit of Docker’s competition also lacks this, on purpose. Between that and the other items on the list, the fairest comparison is not to fully-featured container *engines* like Docker and Podman but to the container *runner* at their heart:

* **runc**: 14 MiB(^This is the runner underpinning `containerd`, thus also Docker, although it precedes it. Long before they created `containerd`, it underpinned `dockerd` instead. Because it is so primordial, a good many other container engines are also based on it.)
* **crun**: 0.5 MiB(^This is Podman’s alternative to `runc`, written in C to make it smaller. Early versions of Podman once relied on `runc`, and it can still be configured to use it, but the new default is to use the slimmer but feature-equivalent `crun`.)
* **systemd-nspawn**: 1.3 MiB(^[This][sdnsp] is the bare-bones OCI image runner built into systemd, with a feature set fairly close to that of `container.npk`. The size above is for version 252 of this program’s parent [`systemd-container`][sdcnt] package as shipped on EL9.)
* **systemd-nspawn**: 1.3 MiB(^[This][sdnsp] is the bare-bones [OCI] image runner built into systemd, with a feature set fairly close to that of `container.npk`. The size above is for version 252 of this program’s parent [`systemd-container`][sdcnt] package as shipped on EL9.)

One reason `container.npk` is far smaller than even the smallest of these runners is that the engines delegate much of what RouterOS lacks to the runner, so that even then it’s an unbalanced comparison. The [`kill`](#kill), [`ps`](#ps), and [`pause`](#pause) commands missing from `container.npk` are provided in Docker Engine way down at the `runc` level, not up at the top-level CLI.

With this grounding, let us dive into the details.

[caps]:   https://www.man7.org/linux/man-pages/man7/capabilities.7.html
[CoW]:    https://en.wikipedia.org/wiki/Copy-on-write
[OCI]:    https://opencontainers.org/
[rlimit]: https://www.man7.org/linux/man-pages/man2/getrlimit.2.html
[sdcnt]:  https://packages.fedoraproject.org/pkgs/systemd/systemd-container/
[sdnsp]:  https://wiki.archlinux.org/title/Systemd-nspawn


## <a id="create" name="load"></a>Container Creation

## <a id="compat"></a>It Only Supports Intel and ARM

MikroTik has shipped an awful lot of MIPS-based product over the years, and it continues to do so, most recently as of this writing in their [CRS518-16XS-2XQ-RM](https://mikrotik.com/product/crs518_16xs_2xq). Atop that, there are other CPU architectures in the historical mix like PowerPC and TILE. MikroTik doesn’t ship a `container.npk` for any of these platforms.

But why not?

The simple reason is, the major OCI image build toolchains — mainly `docker buildx` and its clones — don’t target these other CPU types, a fact you can verify for yourself by running…
The simple reason is, the major [OCI] image build toolchains — mainly `docker buildx` and its clones — don’t target these other CPU types, a fact you can verify for yourself by running…

    $ docker run --privileged --rm tonistiigi/binfmt

“But **a-hah**,” you cry! “There’s MIPS *and* PPC in that list!” You then demand, “Where’s my build of `container.npk` for them, then?”

Did you overlook the “64” in those outputs? These are for modern 64-bit versions of these CPUs, but MikroTik never shipped any 64-bit MIPS or PowerPC CPUs, not even the 100G behemoth linked above, which gets by with a 32-bit MIPSBE based CPU because it is designed as a switch, not a router, offloading nearly all traffic to the switch ASIC.

## <a id="exec"></a>`exec`

There is no way in RouterOS to execute a command inside a running container short of `/container/shell`, which of course only works if there is a `/bin/sh` inside the container.


## <a id="export"></a>`export`/`save`

There is no way to produce a tarball of a running container’s filesystem or to save its state back to an OCI image tarball.
There is no way to produce a tarball of a running container’s filesystem or to save its state back to an [OCI] image tarball.

The [documented advice][imgtb] for getting such a tarball is to do this on the PC side via `docker` commands, then upload the tarball from the PC to the RouterOS device.

[imgtb]: https://help.mikrotik.com/docs/display/ROS/Container#Container-c)buildanimageonPC


## <a id="history"></a>`history`

A more direct alternative would be to shell into the container and run whatever it has for a `top` command, but of course that is contingent on any of that being available.


## <a id="push"></a>`push`/`pull`

RouterOS maintains no local image cache, thus cannot push or pull images.

While it _can_ pull from an OCI image repo, it does so as part of `/container/add`, which is closer to a `docker create` command than to `docker pull`.
While it _can_ pull from an [OCI] image repo, it does so as part of `/container/add`, which is closer to a `docker create` command than to `docker pull`.

There is no equivalent at all to `docker push`.


## <a id="rename"></a>`rename`

RouterOS doesn’t let you set the name on creation, much less rename it later. The closest you can come to this is to add a custom `comment`, which you can both set at “`add`” time and after creation.

## <a id="rm"></a>`rm`

RouterOS spells this `/container/remove`, but do be aware, there is no equivalent for `docker rm -f` to force the removal of a running container. RouterOS makes you stop it first.

Another knock-on effect to be aware of stems from the lack of a local image cache: removing a container and reinstalling it from the *same* remote image requires RouterOS to re-download the image, even when done back-to-back, even if you never start the container between and thereby cause it to make changes to the expanded image’s files. You can end up hitting annoying rate-limiting on the “free” registries in the middle of a hot-and-heavy debugging session due to this. Ask me how I know. 😁

The solution is to produce an OCI image tarball in the format subset that `/container/add file=…` will accept.
The solution is to produce an [OCI] image tarball in the format subset that `/container/add file=…` will accept.

But that brings up a new limitation worth mentioning: RouterOS isn’t a completely OCI-compliant implementation. It can’t handle multi-platform image tarballs, for one. You have to give the matching `--platform` option when downloading the tarball to get something `container.npk` will accept.
But that brings up a new limitation worth mentioning: `container.npk` isn’t 100% OCI-compliant. It can’t handle multi-platform image tarballs, for one. You have to give the matching `--platform` option when downloading the tarball to get something `container.npk` will accept.


## <a id="search"></a>`search`

There is no equivalent to this in RouterOS. You will need to connect to your image registry of choice and use its search engine.