Fix Docker Compose 'network not found' Error: Error response from daemon: network myapp_default not found

The Error

Error response from daemon: network myapp_default not found

This pops up when you run docker compose start or docker compose up on containers that were previously stopped — and Docker can't find the network those containers expect to join.

Why This Happens

Docker Compose creates a dedicated network for each project, named {project}_default by default. That network gets orphaned or deleted when:

• You ran docker compose down (which removes the network) then tried to restart with docker compose start instead of up
• Someone manually pruned Docker networks: docker network prune
• The project directory was renamed — changing the project name means the expected network name no longer matches
• Another tool or script cleaned up unused networks between runs

The containers still exist in stopped state. They remember which network they belong to — but that network is gone.

Step-by-Step Fix

Option 1: Recreate Everything (Quickest)

No need to preserve container state? Just tear it all down and bring it back up:

docker compose down
docker compose up -d

docker compose down removes stopped containers and networks cleanly. docker compose up creates a fresh network and starts everything. This works 90% of the time.

Option 2: Recreate Only the Missing Network

Want to keep your existing containers and just fix the network? Create it manually:

# Check what network name is expected
docker compose config | grep -A5 'networks'

# Confirm it's actually missing
docker network ls | grep myapp

# Create it
docker network create myapp_default

Then start the services:

docker compose start

Network names follow the pattern {project_name}_default. Your project name is usually the directory name — confirm it with:

docker compose config --format json | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('name',''))"

Or just read the error message — it already tells you exactly which network is missing (myapp_default in this case).

Option 3: Explicitly Define the Network in compose.yaml

Tired of this recurring? Pin the network in your compose file so you control its lifecycle:

services:
  web:
    image: nginx
    networks:
      - app-net
  db:
    image: postgres
    networks:
      - app-net

networks:
  app-net:
    name: myapp_default   # fixed name, won't change with directory rename
    driver: bridge

A fixed name means renaming your project directory won't break anything. The network name stays stable regardless of where the project lives.

Option 4: Use an External Network

Multiple Compose stacks sharing the same network? Declare it as external:

# Create it once manually
docker network create shared_net

# In compose.yaml
networks:
  shared_net:
    external: true

With external: true, Compose won't touch the network on up or down — you manage its lifecycle separately. This is the right call for shared databases or reverse proxies like Traefik.

Verify the Fix

# Confirm the network exists
docker network ls | grep myapp_default

# Check containers are attached to it
docker network inspect myapp_default

# Confirm services are running
docker compose ps

In docker network inspect, check the Containers section. Once your services are up, they should all appear there.

Tips

Always use docker compose down, not just stop

docker compose stop pauses containers but leaves them and their network references intact. docker compose start can resume them just fine. The trouble starts when the network vanishes between stop and start — usually from a docker network prune. After any manual network cleanup, use docker compose up instead of start.

Watch out for directory renames

Moving your project folder — say, mv myapp myapp-v2 — changes the Compose project name and breaks the expected network name. Stopped containers still reference myapp_default, but Compose now looks for myapp-v2_default. Lock in the project name with a .env file:

# .env
COMPOSE_PROJECT_NAME=myapp

Debugging network subnet conflicts

In busy environments with many stacks, Docker sometimes fails to recreate a network due to subnet conflicts. If docker compose up hangs on network creation, inspect your existing networks and their subnets first. The Subnet Calculator at ToolCraft makes it easy to work out CIDR ranges and avoid overlap. You can also hardcode a subnet in compose.yaml:

networks:
  app-net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/16

Clean up orphaned containers after a network reset

# Remove containers that no longer have a valid network
docker compose down --remove-orphans
docker compose up -d

--remove-orphans deletes containers for services no longer in your compose file. Run this after any major network reset to start clean.