*   <a id="create-health-cmd"></a>**`--health-cmd`**: Because health-checks are often implemented by periodic API calls to verify that the container continues to run properly, the logical equivalent under RouterOS is to [script] calls to [`/fetch`](https://help.mikrotik.com/docs/display/ROS/Fetch), which then issues `/container/{stop,start}` calls to remediate any problems it finds.

*   <a id="create-init"></a>**`--init`**: Although there is no direct equivalent to this in RouterOS, nothing stops you from doing it the old-school way, creating a container that calls “`ENTRYPOINT /sbin/init`” or similar, which then starts the subordinate services inside that container. It would be somewhat silly to use systemd for this in a container meant to run on RouterOS in particular; a more suitable alternative would be [Alpine’s OpenRC](https://wiki.alpinelinux.org/wiki/OpenRC) init system, a popular option for managing in-container services.

*   <a id="create-label"></a>**`--label`**: The closest equivalent is RouterOS’s `comment` facility, which you can apply to a running container with “`/container/set 0 comment=MYLABEL`”.

*   <a id="create-mac-address"></a>**`--mac-address`**: If RouterOS had this, I would expect it to be offered as “`/interface/veth/set mac-address=…`”, but that does not currently exist. As it stands, a VETH interface’s MAC address is random, same as the default behavior of Docker.
*   <a id="create-mac-address"></a>**`--mac-address`**: RouterOS 7.20 added an equivalent of this as “`/interface/veth/set mac-address=…`”. If left unset, a VETH interface’s MAC address is random, same as the default behavior of Docker.

*   <a id="create-mount"></a>**`--mount`**: The closest equivalent to this in RouterOS is quite different, being the `/container/mounts/add` mechanism. The fact that you create this ahead of instantiating the container might make you guess this to be a nearer match to a “`docker volume create …`” command, but alas, there is no container volume storage manager. In Docker-speak, RouterOS offers bind-mounts only, not separately-managed named volumes that only containers can see.

    Prior to RouterOS 7.20, there was an additional limitation here: `container.npk` could bind-mount whole directories only, not single files as Docker and Podman allow. This was a particular problem when trying to inject a single file under `/etc` since the workaround was to copy the entire subdirectory out of the container, modify the one file you needed changed, and then map the whole mess back in over the top.

*   <a id="create-network"></a>**`--network`**: This one is tricky. While there is certainly nothing like “`/container/add network=…`”, it’s fair to say the equivalent is, “RouterOS.” You are, after all, running this container atop a highly featureful network operating system. Bare-bones the `container.npk` runtime may be, but any limitations you run into with the network it attaches to are more a reflection of your imagination and skill than to lack of command options under `/container`.