Docker Run Command Generator

Docker run command generator with safe shell quoting

The docker run command generator assembles a command that starts one container from a chosen image. Set its name, port mapping, one volume, an environment file and stop behavior to receive a readable multi-line command prepared for a POSIX shell.

The tool does not run Docker and does not upload an image. Its result is plain text for you to review and copy. Every form value becomes a separate argument, while the image stays last because Docker treats everything after it as the container process and its arguments. Validation rejects incomplete port mappings, dangerous mounts and options that the Docker CLI will not accept together.

How settings become command arguments

Step by step

1. Enter a complete image reference with a version, such as nginx:1.27-alpine. Avoid latest when repeatable startup matters.
2. Give the container a name. You can then type docker logs web-app instead of finding a generated identifier.
3. Fill in both ports or clear both fields. The host port binds to 127.0.0.1, so the service is not accidentally made public.
4. Optionally add a mount in the form source:/target:ro and a path to an environment file.
5. Choose stop behavior, generate the command, read every argument and only then run it in your terminal.

docker run \
  -d \
  --restart unless-stopped \
  --name 'web-app' \
  --publish 127.0.0.1:8080:80 \
  --volume './public:/usr/share/nginx/html:ro' \
  'nginx:1.27-alpine'

Shell quoting and injection resistance

Spaces, apostrophes, semicolons and dollar signs have special meaning to a shell. Concatenating -v with raw form input can split an argument or execute another command. This generator wraps dynamic values in single quotes and represents an apostrophe inside a value with the portable POSIX sequence. Flags are fixed strings and are added separately. A path containing spaces therefore reaches the Docker client as one argument.

Quoting protects shell syntax, but it cannot make every configuration wise. The tool rejects mounts of the host root and docker.sock, because either can give a container administrator-like control over the host. It does not offer --privileged. If an application only needs one writable directory, expose that directory rather than a broad portion of the file system.

Ports, networks and external access

The mapping 127.0.0.1:8080:80 means that clients connect to host port 8080, Docker forwards traffic to port 80 in the container, and only the loopback interface accepts the connection. This is a good baseline behind a local Nginx proxy or an SSH tunnel. To expose the service publicly, deliberately change the address after generation and configure a firewall and TLS.

An EXPOSE instruction in a Dockerfile does not publish a port. It documents an image; --publish creates access. Prepare HTTP-layer rules with the .htaccess generator, or describe a cluster rollout with the Kubernetes Deployment generator. For several cooperating services, a declarative Compose file is usually easier to review.

Volumes and the environment file

A bind mount connects a concrete host path to an absolute path in the container. The :ro suffix prevents writes from the container and should be the default for configuration and static files. Relative source paths are resolved from the directory where the Docker client runs. The generator quotes the entire mapping as a single argument.

Use the gitignore generator to prepare patterns for files that must stay outside an image context, and check declarative configuration with the YAML validator. These tools do not replace a review of access rights and host-specific policy.

Restart policies and one-off containers

--restart unless-stopped fits a service intended to stay up. --rm fits a migration, build or one-time script that should disappear after exit. Docker rejects a restart policy combined with automatic removal, so this generator reports an error rather than producing a command that is guaranteed to fail.

Frequently asked questions