Disable a Docker Plugin Without Breaking Its Consumers

You will disable one installed Docker plugin, confirm that Docker reports it as inactive, and know how to enable it again if a workload needs it. Allow about five minutes for the checks. You need Docker CLI access to a running Docker daemon and the name or ID of an installed plugin.

Before you start

Disabling a plugin changes the Docker host, so treat the operation as service-affecting. A volume, network, logging, authorisation or other integration may depend on the plugin. If you are working on a shared host, identify the affected containers and arrange a maintenance window before continuing.

The installed command is Docker Community Edition CLI 29.8.1 on this system. Its syntax is:

docker plugin disable [OPTIONS] PLUGIN

The command needs access to the Docker daemon. That can mean membership of the docker group, a suitable DOCKER_HOST connection, or elevated privileges according to the host setup. The command itself does not automatically require sudo; do not add it unless your daemon access requires it.

1. List installed plugins

Start with a read-only inventory. The ENABLED column tells you whether a plugin is active, while the NAME column gives the reference you can pass to the disable command.

docker plugin ls

A host with no installed plugins produces a header similar to this:

ID        NAME      DESCRIPTION   ENABLED

With a plugin installed, record its complete name, including a tag if Docker shows one. You can usually use its name or ID, but copying the value from this listing avoids a typo.

2. Check what uses the plugin

Inspect the containers and service definitions that might use the plugin before changing its state. For a quick view of running containers, use:

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Then inspect the plugin itself for its declared settings and capabilities:

docker plugin inspect <PLUGIN_REFERENCE>

Replace <PLUGIN_REFERENCE> with the name from step 1, for example vendor/example-plugin:latest. Look for the capability and settings that explain why the plugin was installed. A volume plugin can be tied to mounts, while a network or logging plugin can sit on a running container's path.

Docker normally refuses to disable a plugin that still has references, such as volumes or networks. That refusal is a safety boundary. Resolve the references first or plan to use the force option only when you understand the impact.

3. Disable the plugin normally

Run the command without force first:

docker plugin disable <PLUGIN_REFERENCE>

For a successful operation, Docker prints the plugin reference, for example:

vendor/example-plugin

This stops the plugin and marks it inactive. It does not uninstall or remove the plugin, and its configuration remains available for a later enable operation.

If Docker reports that the plugin has active references, do not immediately retry with --force. Find the containers, volumes, networks or services using it, then stop or reconfigure those consumers using your normal deployment process. Stopping a consumer can itself interrupt service, so record the change and its rollback before applying it.

4. Verify the disabled state

Ask Docker for the plugin list again and check that the target now shows false in ENABLED:

docker plugin ls --filter enabled=false

To make the check unambiguous for one plugin, format the listing as a small, machine-readable line:

docker plugin ls --format '{{.Name}} enabled={{.Enabled}}'

Expected output for the target is similar to:

vendor/example-plugin:latest enabled=false

Also check the workload that motivated the change. A disabled plugin may leave existing Docker objects present while making new mounts, networks or other operations fail. A clean CLI result is not proof that every consumer is healthy.

When force is appropriate

The only option in the installed command is -f, also written --force. It forces the disable of an active plugin:

docker plugin disable --force <PLUGIN_REFERENCE>

This is a disruption switch, not a way to repair a misspelled reference or bypass investigation. Use it only when the references are understood, the service impact is acceptable, and you have a recovery path. Existing containers or resources may stop working when their plugin is no longer available.

Restore the plugin

If the disabled plugin is needed again, enable the existing installation:

docker plugin enable <PLUGIN_REFERENCE>

Docker prints the plugin reference on success. Verify the state:

docker plugin ls --format '{{.Name}} enabled={{.Enabled}}'

Look for enabled=true, then test the dependent workload. If enabling fails, inspect the daemon error, confirm that the plugin is still installed, and check whether its host paths, devices or permissions are available. Re-enabling does not recreate a plugin that has been removed.