Remove Docker Plugins Without Surprising Running Workloads

You will remove one or more local Docker plugins after checking whether they are enabled, and verify that they are gone. Allow about ten minutes for a single plugin, plus time to identify any containers or services that depend on it. The examples use Docker Community Edition CLI 29.8.1, installed from the docker-ce-cli package as version 5:29.8.1-1~ubuntu.24.04~noble.

This is a destructive operation. docker plugin rm does not ask for confirmation, and the local plugin is not restored by an undo command. You normally need access to the Docker daemon, which may mean using your account's Docker group or sudo on a host configured that way. Do not add sudo automatically: it changes which Docker context and configuration are used.

1. Check the command and list the target

Start with read-only checks. The command accepts one or more plugin names or identifiers. Use the exact name shown by docker plugin ls, including a tag if the listing shows one:

$ docker plugin rm --help
Usage:  docker plugin rm [OPTIONS] PLUGIN [PLUGIN...]

Remove one or more plugins

Options:
  -f, --force   Force the removal of an active plugin
$ docker plugin ls --no-trunc
ID        NAME                         DESCRIPTION             ENABLED
abc123    example/vendor-plugin:latest Example plugin          false

The listing is host-specific. If it is empty, there is no locally installed plugin to remove. Do not substitute an image name, container name or registry URL just because it looks similar. Check the name first, then inspect the plugin if you need its full configuration:

$ docker plugin inspect 'example/vendor-plugin:latest'

Checkpoint: write down the exact plugin name you intend to remove. Stop here if it is used by a production container, a Swarm service or a storage path you have not checked.

2. Confirm whether the plugin is enabled

The final column from docker plugin ls is the important boundary. Docker does not normally remove an enabled plugin. The installed CLI's relevant rule is represented by the single option -f or --force, which forces removal of an active plugin.

$ docker plugin ls
ID        NAME                         DESCRIPTION             ENABLED
abc123    example/vendor-plugin:latest Example plugin          false

For an enabled plugin, treat disabling it as a service-disrupting change. Find out what depends on it before proceeding. A volume plugin, for example, may be involved in a container's storage path; removing it can make that workload unable to start or access its data. The plugin does not have to be running in a foreground terminal for this risk to exist.

3. Disable an active plugin deliberately

If the plugin is enabled, disable it in a planned maintenance window. This changes Docker state and may interrupt workloads, so it is not an ordinary read-only check:

$ docker plugin disable 'example/vendor-plugin:latest'
example/vendor-plugin:latest
$ docker plugin ls
ID        NAME                         DESCRIPTION             ENABLED
abc123    example/vendor-plugin:latest Example plugin          false

The exact success line is the plugin reference, not a general health report. Recheck that ENABLED is false before removal. The docker plugin disable command also has a force option, but forcing disable can interrupt a plugin that is still serving a workload. Use it only when you understand the impact.

There is no state rollback command in this workflow. If you disable the wrong plugin and it is safe to restore service, enable the same plugin again and verify it:

$ docker plugin enable 'example/vendor-plugin:latest'
$ docker plugin ls

If you are unsure which containers or services depend on it, do not continue to removal. Record the current plugin reference and investigate the workload configuration first.

4. Remove a disabled plugin

Once the plugin is disabled and you have accepted the loss of the local installation, remove it by name:

$ docker plugin rm 'example/vendor-plugin:latest'
example/vendor-plugin:latest

You can remove several disabled plugins in one invocation. Review every name before pressing Enter because the command applies to all of them:

$ docker plugin rm 'example/vendor-plugin:latest' 'example/old-plugin:2.4'
example/vendor-plugin:latest
example/old-plugin:2.4

Do not use shell expansion to build this list from an unreviewed command such as docker plugin ls -q. A broad removal can delete plugins that belong to unrelated applications. If a plugin is enabled, the ordinary removal should fail rather than silently disabling it. That failure is a useful safety boundary.

5. Verify the removal

List the plugins again and query the exact reference. The first check should no longer show the plugin:

$ docker plugin ls
ID        NAME                         DESCRIPTION             ENABLED
$ docker plugin inspect 'example/vendor-plugin:latest'
Error response from daemon: plugin "example/vendor-plugin:latest" not found

Output formatting varies with the Docker version and daemon, but the decisive result is that the plugin is absent from docker plugin ls and an inspect of that exact local reference reports that it is not found. A missing plugin error before removal means you probably supplied the wrong name or are talking to a different Docker context.

Check the context if the result does not match what you expected:

$ docker context show
default
$ docker info --format '{{.ServerVersion}}'
29.8.1

Only use sudo consistently if the daemon requires it. Running the listing as one user and the removal as another can make a context or permission problem look like a missing plugin.

6. Recover by reinstalling the exact plugin

Removal is local. It does not remove a plugin from its registry, but Docker does not retain a one-command rollback for the deleted installation. If the plugin is still available, reinstall its exact reference through your normal change process:

$ docker plugin install 'example/vendor-plugin:latest'
$ docker plugin ls

Installation may ask you to approve privileges and may enable the plugin by default, depending on the plugin and the options you choose. Recheck the plugin's requested permissions, settings and data paths rather than assuming the old configuration has returned. If the tag moved since the original installation, use a recorded immutable digest or an approved version instead of blindly using latest.

If the plugin is unavailable or its configuration was not recorded, stop the affected workload and follow your platform's recovery procedure. Do not recreate permissions or mount paths from memory on a production host.