19 Docker CLI Commands

Docker CLI commands are organized around a consistent, resource-oriented structure, management commands grouped by resource type, alongside legacy, flatter top-level commands retained for backward compatibility, and an extensible plugin system that allows entirely new command groups like buildx, compose, and scout to integrate into the same docker CLI without being part of the core binary itself.

Management commands grouped by resource

Modern Docker CLI usage favors commands grouped explicitly under their resource type, container, image, network, volume, system, which makes the available actions for a given resource type discoverable together rather than scattered across a flat, undifferentiated list of top-level commands:

docker container ls
docker container stop my-api
docker container logs my-api

docker image ls
docker image prune
docker image inspect my-api

This grouped structure scales considerably better as the CLI's overall surface area grows, since a new action for managing volumes, for instance, naturally fits under docker volume rather than needing its own, separately memorable top-level command name.

Legacy flat commands remain available

Many of the most frequently used actions also remain available as shorter, flat top-level commands, retained specifically for backward compatibility and because muscle memory built up over years of Docker usage continues to favor them:

docker ps
docker images
docker rm
docker rmi

docker container ls
docker image ls
docker container rm
docker image rm

Both forms are entirely equivalent and supported indefinitely; choosing between them is purely a matter of personal or team preference, with the grouped form offering somewhat better discoverability for less frequently used actions and the flat form offering brevity for the most common, routine ones.

Discovering available commands and options

The --help flag, available at every level of the command hierarchy, surfaces exactly what subcommands and options exist at that specific level, which is generally faster and more reliably current than searching external documentation for a specific, exact flag name:

docker --help
docker container --help
docker container logs --help

This layered help structure means discovering a specific, less commonly used flag for a specific command is usually just one or two --help invocations away, rather than requiring a search through external documentation that might be for a different Docker version than the one actually installed.

Plugin-based command extensibility

Several major pieces of Docker functionality, buildx, compose, scout, are implemented as CLI plugins, separate binaries that integrate into the docker command namespace, rather than being built directly into the core Docker CLI binary itself:

docker buildx build --platform=linux/amd64,linux/arm64 .
docker compose up -d
docker scout cves my-api:1.4.2

docker plugin list

This plugin architecture allows these substantial pieces of functionality to be developed, versioned, and updated somewhat independently of the core CLI release cycle, while still feeling like a fully integrated, native part of the overall docker command experience from a user's perspective.

Verifying which plugins are actually installed

Because plugin availability can vary across different installation methods and Docker versions, confirming a specific plugin is actually present before relying on its commands avoids confusion when a command that works on one machine is unexpectedly unavailable on another:

docker compose version
docker buildx version

An error indicating an unknown command, rather than the plugin's own expected output, is the direct signal that the specific plugin is not installed or not correctly registered with the current Docker CLI installation, which is worth checking directly rather than assuming every Docker installation includes every commonly discussed plugin by default.

Command output formatting options

Most listing commands support a --format flag accepting a Go template, allowing output to be reshaped into exactly the fields and structure needed, which is particularly useful for scripting against command output reliably rather than parsing the default, human-oriented table format:

docker ps --format "{{.Names}}: {{.Status}}"
docker images --format '{{json .}}'

Requesting JSON output specifically, where supported, is generally the more robust choice for any script that needs to reliably parse command output, since JSON has an unambiguous, well-defined structure that the default table format does not guarantee will remain stable across versions.

Common mistakes

• Assuming the grouped, resource-oriented command form and the legacy flat form behave differently, when they are functionally identical and equally valid, current choices.
• Searching external documentation for a specific flag's exact name rather than using the CLI's own, always-current --help output at the relevant command level.
• Assuming every Docker installation includes every commonly discussed plugin like buildx or compose by default, rather than verifying a specific plugin's actual presence directly.
• Parsing the default, human-oriented table output in scripts rather than requesting a more reliably structured format like JSON through the --format flag.
• Not recognizing that substantial Docker functionality is implemented through the plugin architecture, leading to confusion when a plugin-provided command behaves or updates somewhat independently of the core CLI's own release cycle.

Docker CLI commands follow a consistent, resource-grouped structure alongside retained legacy flat commands, with --help available at every level for current, reliable discovery, and an extensible plugin architecture that integrates substantial additional functionality, buildx, compose, scout, seamlessly into the same overall command namespace without requiring it to be built directly into the core CLI binary.