docker run on wslc
docker run is partial on wslc 2.9.4.0. The command exists as wslc run, but its flags, defaults or output format do not match Docker byte-for-byte, so the shape of your invocation decides whether it needs an edit.
| Docker command | docker run |
|---|---|
| Status on wslc 2.9.4.0 | Partial |
| wslc command | wslc run |
| Verified against | wslc 2.9.4.0, windows-2025 runner |
Measured detail. -d, -p, -v, -e, --name, --rm, -it, -m all exist. No --device, --platform or --restart. Memory units must be uppercase: 512M works, 512m is rejected.
The wslc equivalent
# Docker
docker run
# wslc
wslc runwslc run [<options>] <image> [<command>] [<arguments>...]
Straight from wslc run --help on wslc 2.9.4.0 .
| Argument | Meaning |
|---|---|
image | Image name |
command | The command to run |
arguments | Arguments to pass to container's init process |
| Flag | Meaning |
|---|---|
--cidfile | Write the container ID to the provided path |
--cpus | Number of CPUs (e.g. 0.5, 1, 2.5) |
-d,--detach | Run container in detached mode |
--dns | IP address of the DNS nameserver in resolv.conf |
--dns-option | Set DNS options |
--dns-search | Set DNS search domains |
--domainname | Container domain name |
--entrypoint | Specifies the container init process executable |
-e,--env | Key=Value pairs for environment variables |
--env-file | File containing key=value pairs of env variables |
--gpus | Add GPU devices to the container ('all' to pass all GPUs) |
--health-cmd | Command to run to check container health |
--health-interval | Time between running the health check (e.g. 30s, 1m30s) |
--health-retries | Consecutive failures needed to report the container as unhealthy |
--health-start-period | Start period for the container to initialize before health-check countdown (e.g. 30s, 1m30s) |
--health-timeout | Maximum time to allow one health check to run (e.g. 30s, 1m30s) |
-h,--hostname | Container host name |
-i,--interactive | Attach to stdin and keep it open |
-l,--label | Set metadata on an object |
-m,--memory | Memory limit (e.g. 512M, 1G) |
--name | Name of the container |
--network | Connect a container to a network |
--network-alias | Add a network-scoped alias for the container |
--no-healthcheck | Disable any container-specified health check |
-p,--publish | Publish a port from a container to host |
-P,--publish-all | Publish all exposed ports to random host ports |
--rm | Remove the container after it stops |
--shm-size | Size of /dev/shm (e.g. 64M, 1G) |
--stop-signal | Signal to stop the container |
--stop-timeout | Timeout (in seconds) to stop the container before killing it (-1 for no timeout) |
--tmpfs | Mount tmpfs to the container at the given path |
-t,--tty | Open a TTY with the container process. |
--ulimit | Ulimit options (format: <name>=<soft>[:<hard>], use -1 for unlimited) |
-u,--user | User ID for the process (name|uid|uid:gid) |
-v,--volume | Bind mount a volume to the container |
-w,--workdir | Working directory inside the container |
How we know
Confirmed by reading wslc --help output and, where the behaviour depends on execution rather than argument parsing, by running the command against wslc 2.9.4.0 on a Windows Server 2025 GitHub Actions runner. Unrecognized flags and subcommands fail loudly on wslc -- the parser answers Argument name was not recognized for the current command and exits non-zero -- so a typo is unlikely to be misread as support. The risk runs the other way: a Docker habit that happens to parse (like wslc ps still working) can mask a difference in what the flags underneath it do.
Claims on this site are re-checked by a scheduled workflow that runs the commands again on
a fresh Windows Server 2025 runner and fails when a documented behaviour stops matching
reality. wslc ships roughly every two weeks during the preview, so treat any page that
disagrees with your own machine as the page being stale, and check the version you are on
with wslc version.
Where this fits
This is one row of the full Docker to wslc cheat sheet,
which covers every command and every flag on a single page. If the workload you are
porting uses Docker Compose rather than bare docker invocations, start from
Compose key support instead -- docker run rarely appears verbatim in a compose.yaml, and the key-level page maps YAML fields
directly to the flags shown above. For a whole script at once, paste it into the
command converter and get every line classified in the same pass.