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 you stick to a compatible subset of the Docker Engine API, implementation details cease to matter up at the control plane’s level of abstraction.

If you find yourself needing a control plane for your routers’ containers, you will likely need to write it yourself.

[ROAPI]: https://help.mikrotik.com/docs/spaces/ROS/pages/47579162/REST+API


# <a id="oci" name="compliance"></a>OCI Compliance

RouterOS benefits greatly from the existence of the [Open Container Initiative][OCI] specification process. It gives them a vendor-independent standard to target, rather than continually chasing Docker’s current implementation in an _ad hoc_ fashion.

Unfortunately, `container.npk` is not 100% OCI-compliant.

You are likely to run into this class of problems early on when dealing with OCI image tarballs under RouterOS because it cannot currently handle multi-platform image tarballs at all. If you then build a single-platform image or pull one by giving the `--platform` flag, it may still fail to load, depending on how it was built. I’ve found the [Skopeo] tool from the Podman project helpful in fixing this type of problem up:

    $ skopeo copy docker-archive:broken.tar docker-archive:working.tar

In theory, this should result in zero change since it’s converting to the same output format as the input, but more than once I’ve seen it fix up some detail that RouterOS’s container image loader can’t cope with on its own.

Note, incidentally, that we don’t use Skopeo’s `oci-archive` format specifier. I don’t know why, but I’ve had less success with that.

[Skopeo]: https://github.com/containers/skopeo




# <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 `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="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](#compliance) that `/container/add file=…` 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.