Manage Docker Plugins with the docker plugin Command

docker plugin is the umbrella command for listing, inspecting, installing and removing Docker Engine managed plugins. Every plugin you enable is code with real access to your host, and this guide gives you a repeatable workflow for handling that safely. The examples use Docker Community Edition CLI 29.8.1, installed here as docker-ce-cli. Allow about fifteen minutes for an existing plugin, longer if you need to review a plugin's permissions before installing it.

Before you start

• A working Docker daemon and the docker command.
• Permission to talk to that daemon. On many Linux systems that means membership of the docker group; on others, prefix commands with sudo. Use elevated privileges only where your setup actually requires them.

1. Check the command and daemon

The top-level manpage describes docker plugin as the command for managing plugins; its detailed behaviour is split across the subcommands. Start with the installed help and version:

$ docker --version
Docker version 29.8.1, build 4a63305
$ docker plugin --help
Usage:  docker plugin COMMAND

Manage plugins

If your version differs, read that installation's subcommand help before copying an option into a script. If Docker cannot connect to the daemon, fix the daemon or context first; do not try to solve a connection problem by granting a plugin more privileges.

$ docker plugin ls
ID        NAME      DESCRIPTION   ENABLED

2. Inspect what is already installed

List plugins before changing anything. Filter the result when you need to find disabled plugins or a particular capability:

$ docker plugin ls --filter enabled=false
$ docker plugin ls --filter capability=volumedriver
$ docker plugin ls --format '{{.ID}} {{.Name}} enabled={{.Enabled}}'

The available capability filters are volumedriver, networkdriver, ipamdriver, logdriver, metricscollector and authz. An empty result means no installed plugin matches; it does not mean the plugin is safe or even available from a registry.

Use inspect for the detail that matters before enabling or changing a plugin:

$ docker plugin inspect PLUGIN_NAME
$ docker plugin inspect --format '{{.Enabled}} {{.Config.Env}}' PLUGIN_NAME

Swap in the exact name or ID from docker plugin ls for PLUGIN_NAME. Review the plugin's network mode, mounts, devices, capabilities, entrypoint, environment and arguments. The output is JSON by default. Do not paste secrets from environment settings or registry credentials into a ticket or shell history.

3. Install with permissions visible

Use the plugin publisher's documented reference, never an unverified name that just happens to look similar. This keeps the plugin disabled until you have reviewed it:

$ docker plugin install --disable VENDOR/PLUGIN:TAG
Plugin "VENDOR/PLUGIN:TAG" is requesting the following privileges:
 ...
Do you grant the above permissions? [y/N]

Read every requested privilege. A host network, a device such as /dev/fuse, a writable host mount or a capability such as CAP_SYS_ADMIN can materially expand what the plugin's code can do. Press N or interrupt the command if the request looks off.

$ docker plugin ls --filter enabled=false
ID             NAME                 DESCRIPTION          ENABLED
PLUGIN_ID      VENDOR/PLUGIN:TAG    ...                  false

4. Enable only after the review

Enable the installed plugin by its name or ID:

$ docker plugin enable PLUGIN_NAME
VENDOR/PLUGIN:TAG
$ docker plugin ls --filter enabled=true

Enabling starts the plugin and makes its advertised driver available to Docker operations. It can fail here because a required host path, device, kernel feature or configuration value is missing. Check the daemon logs and rerun docker plugin inspect PLUGIN_NAME; do not reach for --timeout as a way to paper over a startup failure. The installed default timeout for enable is 30 seconds, and the option only changes the HTTP client timeout in seconds.

To stop a plugin without removing it, disable it:

$ docker plugin disable PLUGIN_NAME
VENDOR/PLUGIN:TAG

Disabling can disrupt containers or volumes that depend on the plugin, so check those consumers first. If Docker refuses because the plugin is active, the installed command offers docker plugin disable --force PLUGIN_NAME, but force can break workloads. Use it only in a controlled maintenance window, then verify the dependent services before restarting them.

5. Change settings only while disabled

docker plugin set changes supported environment variables, mount sources, device paths or arguments, and the plugin must be disabled first. Inspect the current value, make one deliberate change, then inspect it again:

$ docker plugin disable PLUGIN_NAME
$ docker plugin inspect --format '{{.Config.Env}}' PLUGIN_NAME
$ docker plugin set PLUGIN_NAME SETTABLE_KEY=VALUE
$ docker plugin inspect --format '{{.Config.Env}}' PLUGIN_NAME
$ docker plugin enable PLUGIN_NAME

Only use a key the plugin's configuration marks as settable; this is not a general-purpose edit mechanism. Record the old value before changing it. To undo the example, disable the plugin, set the key back to its recorded value, inspect the result, then enable it again. Restoring a mount source or device path can still affect running workloads, so verify the host path before re-enabling.

6. Remove a plugin when you have a rollback plan

Removal is the last step, not the first troubleshooting move. Disable the plugin and check that no container, volume or service still depends on it:

$ docker plugin disable PLUGIN_NAME
$ docker plugin rm PLUGIN_NAME
VENDOR/PLUGIN:TAG
$ docker plugin ls

docker plugin rm removes one or more installed plugins. The installed CLI also supports --force to remove an active plugin, but that is disruptive and can strand dependent Docker resources. Keep the exact image reference and any setting values in case you need to reinstall: a mutable tag can point at a newer image later, so pin a reviewed tag or digest when the publisher offers one.