*   There is no GPU support, not even for bare-metal x86 installs.

[caps]:   https://www.man7.org/linux/man-pages/man7/capabilities.7.html
[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 good many of these limitations stem from those of RouterOS itself. For instance, while RouterOS proper is built atop Linux, and it provides a feature-rich CLI, it is nothing like a Linux command shell. (More on this [below](#run).)

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, `container.npk` compares most closely to a container *runner* like`runc`, `crun`, or `systemd-nspawn` than to a full *engine* like Docker or Podman.
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, `container.npk` compares most closely to a container *runner* like `runc`, `crun`, or `systemd-nspawn` than to a full *engine* like Docker or Podman.

With this grounding, let us dive into the details.


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

The single biggest area of difference between the likes of Docker and the RouterOS `container.npk` feature is how you create containers from OCI images. It combines Docker’s `create` and `load` commands as `/container/add`, the distinction expressed by whether you give it the `remote-image` or `file` option, respectively.

The “sleep 3600” hack is necessary because `container.npk` lacks any notion of interactive mode. In order to keep a container of this type from starting, doing a whole lot of _nothing_, and then stopping,(^…but not cleaning up after itself as with `--rm`, mind!) you have to give it some type of busy-work to keep it alive. This is a common one, but it only lasts an hour. More complicated methods are difficult to pull off due to the lack of host-side Bourne shell command parsing in RouterOS; the `cmd` option gets passed into the container as a single string, but you only have two to play with, `entrypoint` and `cmd`, so how do you say something like the following?

    docker run alpine:latest 'while true ; do sleep 5 ; done' &

The answer is that if you want a RouterOS container to do anything tricky like that, you need to write your own `ENTRYPOINT` script.

Another bit of fallout from all this is that there can be no equivalent to commands like “`docker run --attach std…`” under RouterOS due to lack of a termios/pty subsystem visible at the RouterOS CLI level.

With all of that to ground us, the rest is far simpler to discuss.


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

For lack of any better organization principle, I’ve chosen to cover these 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 matches fairly well with it, except that I do not currently go into any of its pure extensions, such as its eponymous `pod` command.


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

Although RouterOS proper is built atop Linux, and it provides a feature-rich CLI, it is nothing like a Linux command shell. Even when you SSH in, you’re missing things like a meaningful distinction between stdout and stderr, and the kernel’s underlying termios/pty subsystem is hidden at the RouterOS CLI level.

There is no interactive terminal (stdin/stdout/stderr) in RouterOS to speak of, and you normally run these boxes headless, connecting to their virtual terminal via WinBox or SSH only long enough to reconfigure something before logging back out. The `container.npk` feature is designed to run its subordinate processes purely in the background, with logging suppressed by default. If you say `/container/set logging=yes`, the standard output streams go to the configured logging destination, but there is no way to interactively type commands at the container short of `/container/shell`, which carries the requirement that a `/bin/sh` program exist inside the container.(^You can’t count on that in every container. Indeed, all of [my public containers](https://hub.docker.com/repositories/tangentsoft) elide the shell to reduce the container’s attack surface.) Even then, you’re typing commands at the shell, not at the container’s `ENTRYPOINT` process.
This lack of exposed Linux terminal interfaces stems from the design principle that these boxes are meant to run headless, connecting to their virtual terminal via WinBox or SSH only long enough to reconfigure something before logging back out. 

Consequently, `container.npk` expects to run its subordinate processes purely in the background, with logging suppressed by default. If you say `/container/set logging=yes`, the standard output streams go to the configured logging destination, which you must set *in addition* under `/system/logging`.
All of this explains why RouterOS [lacks](#run) a direct equivalent of “`docker run`”, particularly the common `-it` option pair. The closest `container.npk` comes is its [`shell`](#shell) command implementation.

All of this explains why there are no equivalents of Docker’s `attach` command, nor its “`docker run --attach flag`”, nor the common “`docker run -it`” option pair. The closest `container.npk` comes to all this is its [`shell`](#shell) command implementation, which can connect your local terminal to a true remote Linux terminal subsystem. That isn’t a close “`run -it`” alternative because you’re left typing commands at this remote shell, not at the container’s `ENTRYPOINT` process.

And even then it doesn’t always work, since a good many containers lack a `/bin/sh` program inside the container in the first place, on purpose, typically to reduce the container’s attack surface.(^Indeed, all of [my public containers](https://hub.docker.com/repositories/tangentsoft) elide the shell for this reason.)


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

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