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.


# <a id="tlc"></a>Remaining Top-Level Commands
# <a id="tlc"></a>Top-Level Commands

So ends my coverage of the heavy points. Everything else we can touch on briefly, often by reference to matters covered previously.

For lack of any better organization principle, I’ve chosen to cover the remaining `docker` CLI commands in alphabetical order. I skip over short aliases like `docker rmi` for `docker image rm` in order to cover things only once, and I don’t repeat any of the `create`/`load`/`run` discussion [above](#create). Because Podman cloned the Docker CLI, this ordering matches up fairly well with its top-level command structure as well, the primary exception being that I do not currently go into any of Podman’s pure extensions, ones such as its eponymous `pod` command.
For lack of any better organization principle, I’ve chosen to cover the remaining `docker` CLI commands in alphabetical order. Because Podman cloned the Docker CLI, this ordering matches up fairly well with its top-level command structure as well, the primary exception being that I do not currently go into any of Podman’s pure extensions, ones such as its eponymous `pod` command.


## <a id="build"></a>`build`/`buildx`

RouterOS provides a bare-bones container runtime only, not any of the image building toolchain.


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

Given the [global limitations](#global), it should be no surprise that RouterOS has no way to commit changes made to the current image layer to a new layer.


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

RouterOS completely lacks multi-container orchestration features, including lightweight single-box ones like [Compose](https://docs.docker.com/compose/) or [Kind](https://kind.sigs.k8s.io) virtual clusters.


## `create`/`load`

[Covered above](#create).


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

RouterOS does let you mount a volume inside a container, then use the regular `/file` facility to copy files in under that volume’s mount point, but this is not at all the same thing as the “`docker cp`” command. There is no way to overwrite in-container files with external data short of rebuilding the container or using in-container mechanisms like `/bin/sh` to do the copying for you.

If you come from a Docker or Podman background, their local overlay image stores might lead you into thinking you could drill down into the GUID-named “container store” directories visible under `/file` and perform _ad hoc_ administration operations like overwriting existing config files inside the container, but alas, it does not.

RouterOS doesn’t keep this information.


## <a id="image"></a>`image`/`images`

The lack of a build toolchain means there is no sensible equivalent for the “`docker image build`” subcommand.

The lack of a local image cache means RouterOS has no need for any of these subcommands:
The rest of the missing subcommands are explained by the lack of a local image cache:

*   `history`
*   `import`/`load`/`save`
*   `ls`
*   `prune`
*   `rm`
*   `rm`/`rmi`
*   `tag`
*   `tree`

The rest are implicitly covered elsewhere: [`inspect`](#inspect) and [`push/pull`](#push).
The few remaining subcommands are implicitly covered elsewhere: [`inspect`](#inspect) and [`push/pull`](#push).


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

This is `/container/add file=oci-image.tar` in RouterOS.

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

RouterOS exposes all ports defined for a container in the `EXPOSE` directive in the `Dockerfile`. The only ways to instantiate a container with fewer exposed ports are to either rebuild it with a different `EXPOSE` value or to create a derived container with the `FROM` directive and set a new `EXPOSE` value.

(See also the discussion of [`--publish`](#publish) above.)


## `run`

[Covered above](#run).


## <a id="ps"></a>`ps`/`stats`/`top`

The closest thing in RouterOS is the `/container/print follow*` commands.

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.