List and Filter Docker Networks with docker network ls

Before you delete or debug a network, run docker network ls so you are working from what the daemon has, not an old deployment note.

You will see the networks known to a Docker Engine, narrow the list without changing anything, and produce output suitable for a script or an incident note. Allow about ten minutes for a basic audit. Every example here is read-only unless marked otherwise.

1. Check the CLI and daemon connection

You need the Docker CE CLI and access to a running daemon. The command is normally unprivileged for an account that can already reach Docker. Do not add sudo automatically: Docker group membership, or a rootless Docker context, is an access decision, and Docker access can amount to root-level control of the host.

Check the installed version and active context before you trust the list:

$ docker --version
Docker version 29.8.1, build 4a63305
$ docker context show
default

Your version, context and build will differ. This guide uses Docker 29.8.1 from the installed docker-ce-cli package. A context can point at another host entirely, so confirm it before you treat the result as a local inventory.

Checkpoint: if docker context show names something unexpected, stop and select the right one through your normal Docker context procedure. Never run cleanup commands against a daemon you have not confirmed.

2. List every known network

Run the command with no options for the default table:

$ docker network ls
NETWORK ID     NAME                         DRIVER    SCOPE
cc464906f331   bridge                       bridge    local
116bc0498b82   clientexamplecouk_internal   bridge    local
64a4af5f7dec   deploy_default               bridge    local
3cc148092200   host                         host      local
5391ce445979   meet_default                 bridge    local
cab2eafd058b   newappcx_default             bridge    local
1366d2d6a8a9   none                         null      local

The daemon supplies the rows. NETWORK ID is a display form, while NAME, DRIVER and SCOPE explain how the network is used. Built-in networks commonly include bridge, host and none; Compose and other tooling often add names ending in _default or similar project-specific names.

An empty or unexpectedly short list is not proof that networks do not exist elsewhere. It may just mean the active context or daemon differs from the one you meant.

3. Narrow the result with filters

Filters use key=value. The supported keys are driver, id, label, name, scope and type. Name and ID matching can use a substring, so check the returned rows rather than assume an exact match.

To find user-created networks, use the type filter:

$ docker network ls --filter type=custom
NETWORK ID     NAME                         DRIVER    SCOPE
116bc0498b82   clientexamplecouk_internal   bridge    local
64a4af5f7dec   deploy_default               bridge    local
5391ce445979   meet_default                 bridge    local
cab2eafd058b   newappcx_default             bridge    local

To find networks whose name contains a project fragment, quote the filter if it comes from a shell variable or has shell-significant characters:

$ docker network ls --filter 'name=deploy'
NETWORK ID     NAME            DRIVER    SCOPE
64a4af5f7dec   deploy_default  bridge    local

For a driver or scope check, use the same form:

$ docker network ls --filter driver=bridge --filter scope=local
NETWORK ID     NAME                         DRIVER    SCOPE
cc464906f331   bridge                       bridge    local
116bc0498b82   clientexamplecouk_internal   bridge    local
64a4af5f7dec   deploy_default               bridge    local
5391ce445979   meet_default                 bridge    local
cab2eafd058b   newappcx_default             bridge    local

Tip: read the filter semantics carefully. Repeated filter flags combine as OR, not AND. The example above works because the two different keys narrow the result together in this installed CLI, but repeated values such as --filter type=custom --filter type=builtin ask for either type.

4. Get full IDs or IDs only

The abbreviated ID is fine for a terminal but can be ambiguous in automation. Add --no-trunc for the complete identifier:

$ docker network ls --no-trunc --filter name=deploy
NETWORK ID                                                         NAME            DRIVER    SCOPE
64a4af5f7dece9eabc5ad5b9e8210dedff328fc8f91e11e3891ec307800a3217   deploy_default   bridge    local

The full ID is host-specific, and column spacing can shift with name length. If a script needs identifiers rather than a table, use quiet mode:

$ docker network ls --filter name=deploy --quiet
64a4af5f7dec

Quiet mode prints network IDs only, still in Docker's short display form. Resolve a selected ID with --no-trunc when your consumer needs the full value, and do not parse column positions out of the normal table.

5. Produce stable fields for review or scripts

Use --format when a table is too loose for a report. A Go template can pick fields and add separators:

$ docker network ls --format '{{.Name}}	{{.Driver}}	{{.Scope}}'
bridge  bridge   local
clientexamplecouk_internal  bridge   local
deploy_default  bridge   local
host    host     local
meet_default    bridge   local
newappcx_default       bridge   local
none    null     local

Supported fields include .ID, .Name, .Driver, .Scope, .IPv6, .Internal, .Labels and .Label. Current Docker documentation also lists .CreatedAt; the installed manpage on this host does not, so test that field against your exact CLI version before you rely on it in a portable script.

For machine-readable records, the installed command documents the json format directive:

$ docker network ls --format json
{"CreatedAt":"2026-09-11 15:59:50.151883837 +0100 BST","Driver":"bridge","ID":"cc464906f331","IPv4":"true","IPv6":"false","Internal":"false","Labels":"","Name":"bridge","Scope":"local"}

The timestamp and rows above are examples of the shape, not values to copy into an inventory. Treat each output line as its own JSON object, and verify the format on the CLI version your automation actually runs.

6. Handle failures without changing the host

A connection error usually means the daemon is stopped, the selected context is wrong, or the current account lacks access. Start with read-only checks:

$ docker info
$ docker context ls
$ docker network ls
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Do not repair a service or change socket permissions just to make an inventory command work. If the daemon is managed by systemd, ask the host owner to check its service state. If access is denied, confirm the approved account and context instead of broadening permissions.

Warning: there is no undo step for anything in this guide, because listing, filtering and formatting never create, delete or reconnect networks. But be cautious with examples found elsewhere that pipe docker network ls --filter type=custom -q into docker network rm. That is destructive: it removes networks, can disrupt attached containers, and has no universal recovery command. Review each network and its attached containers before any removal, and keep a separate recovery plan.

Done means