Fixing Docker "Error: No such network" with Compose and CLI

What this error means

Docker could not find a network by the name you referenced. This happens when:

• The network was never created, or it was pruned.
• The name is wrong (typo, wrong project name, or different Docker context).
• You are using Docker Compose and the expected auto-created network does not exist.
• You referenced an external network in Compose without creating it.
• You switched to a different Docker context/daemon or reset/updated Docker.

Quickstart: the fastest fixes

• List networks and confirm the name:

  docker network ls
  

• If the network should exist globally, create it:

  docker network create appnet
  

• If you use Docker Compose, recreate project networks:

  docker compose down
  docker compose up -d
  

• If using an external network in Compose, create it before up:

  docker network create app-shared
  docker compose up -d
  

Common symptoms, causes, and fixes

Minimal working example (Compose)

This example shows a user-defined network that is created automatically by Compose, and a service that uses it.

a version: "3.9"
services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    networks:
      - appnet
networks:
  appnet:
    driver: bridge

Run it:

docker compose up -d
# Access http://localhost:8080

If you instead reference an external network that does not exist:

a version: "3.9"
services:
  web:
    image: nginx:alpine
    networks:
      - appnet
networks:
  appnet:
    external: true
    name: app-shared

You must create it first:

docker network create app-shared
docker compose up -d

Step-by-step diagnosis and fixes

1. Confirm Docker context and daemon

• Check active context:

  docker context ls
  docker context use default  # or your target
  

• If you pointed at a remote daemon earlier, the network may exist there, not locally.

1. List available networks

docker network ls

• Verify the exact network name. Compose-created names are often <project>_<network>.

1. Identify Compose project name

• Compose v2 derives the project name from the directory by default:

  docker compose ls
  docker compose config --services
  docker compose config --profiles
  

• To force a stable project name (and thus stable network names):

  docker compose --project-name myproj up -d
  # Networks will be named like: myproj_appnet
  

1. Recreate networks via Compose

• For auto-managed networks, simply redeploy:

  docker compose down
  docker compose up -d --build
  

• Inspect networks:

  docker network ls | grep myproj
  

1. Create missing external networks

• If your compose file uses external: true:

  docker network create app-shared
  docker compose up -d
  

• For Swarm/overlay networks:

  docker network create -d overlay --attachable app-overlay
  

1. Verify container network attachments

docker inspect <container>

• Look under NetworkSettings.Networks to see attached network names. If absent, reconnect:

docker network connect appnet <container>
# Or disconnect wrong ones
docker network disconnect oldnet <container>

1. Clean up stale networks (carefully)

• Remove a specific network:

  docker network rm oldnet
  

• Prune unused networks:

  docker network prune
  

• Only prune when you understand that unused networks for stopped containers will be removed.

Compose network naming rules (quick reference)

• Default network per project: <project>_default.
• Named networks in compose: <project>_<networkName>.
• external: true uses the provided name: verbatim; Compose will not create it.
• Changing project name or directory changes network names unless you pin --project-name or use name: with external: true.

Performance and operational notes

• Prefer user-defined bridge networks over the default bridge. They provide service discovery and cleaner isolation with small overhead.
• Many networks per container can slow startup and DNS resolution. Keep attachments minimal.
• Overlay networks add control-plane overhead. Use only when needed (Swarm/multi-host). Mark --attachable if standalone containers must join.
• Avoid frequent global prune operations in CI; batching container/network lifecycle reduces churn and startup delays.
• Pin stable project names in CI/CD to avoid repeated network recreation and cross-run conflicts.

Pitfalls to avoid

• Typos and case sensitivity: network names are case-sensitive.
• Mixing docker-compose (v1) and docker compose (v2) can produce different project names. Standardize on v2.
• Assuming networks persist across contexts or daemons. They are local to the Docker host/daemon.
• Declaring external: true without creating the network first.
• Relying on implicit default network when you actually need a named one shared across stacks.

Command cheat-sheet

FAQs

• Why do I still see the error after docker compose up? The project name may differ from before, so the expected <project>_<network> is new. Use --project-name to keep names stable or update references.

• How do I know the exact Compose-created network name? Run docker network ls after docker compose up. It will be <project>_<network> or <project>_default.

• Can multiple Compose projects share a network? Yes. Create a user-defined network once (e.g., docker network create app-shared) and set external: true with name: app-shared in each compose file.

• I’m using Swarm and see the error for an overlay network. What now? Create it with the overlay driver: docker network create -d overlay --attachable NAME, then deploy.

• Does docker network prune break running apps? It only removes unused networks. Running containers keep their networks; however, stopped services expecting those networks later may fail until recreated.