Remove Docker Plugins Without Surprising Running Workloads

A volume plugin can be quietly holding a container's only copy of its data, so docker plugin rm needs a plan, not just a name. This covers removing one or more local Docker plugins after checking whether they are enabled, then verifying they are actually gone. Allow about ten minutes for a single plugin, plus time to work out what depends 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.

1. Check the command and list the target

Start with read-only checks. The command takes one or more plugin names or identifiers; use the exact name shown by docker plugin ls, tag included 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 comes back 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, then inspect the plugin if you need its full configuration:

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

2. Confirm whether the plugin is enabled

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

$ 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 and find out what depends on it first. A volume plugin, for instance, can sit in a container's storage path; removing it can leave that workload unable to start or reach its data. It does not need to be visibly running in a foreground terminal for this risk to exist.

3. Disable an active plugin deliberately

If the plugin is enabled, disable it inside a planned maintenance window: this changes Docker state and can interrupt workloads, so it is not an ordinary read-only step.

$ 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, so recheck that ENABLED reads false before you remove anything. docker plugin disable has its own force option too, but forcing a disable can interrupt a plugin still serving a workload; use it only once you understand the impact.

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

If you are not sure which containers or services depend on it, do not go any further towards removal. Record the current plugin reference and go investigate the workload configuration first.

4. Remove a disabled plugin

Once the plugin is disabled and you have accepted losing 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 call. Review every name before pressing Enter, because the command applies to all of them at once:

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

Do not build this list from an unreviewed command such as docker plugin ls -q through shell expansion; a broad removal can catch plugins belonging to unrelated applications. If a plugin is still enabled, ordinary removal should fail rather than silently disabling it first, and that failure is a useful safety boundary, not a bug to work around.

5. Verify the removal actually happened

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

$ 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

Exact formatting varies by Docker version and daemon, but the decisive result is that the plugin is absent from docker plugin ls and an inspect of that exact reference reports it as not found. A missing-plugin error before you have even removed anything usually means a wrong name, or a different Docker context than you think you are talking to.

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

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

Use sudo consistently or not at all. Listing as one user and removing as another can make a plain 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 keeps no one-command rollback for the deleted installation. If the plugin is still available upstream, 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 chosen. Recheck its requested permissions, settings and data paths rather than assuming the old configuration has quietly come back. If the tag has moved since the original install, use a recorded immutable digest or an approved version instead of blindly pulling latest again.

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