How do I fix "Bind for 0.0.0.0:5432 failed: port is already allocated"?

Check what owns the host port first with ss -ltnp or lsof -i :5432. Stop the conflicting process or change the published port mapping, then recreate the container.

What does "listen tcp 0.0.0.0:8080: bind: address already in use" mean in Docker?

Docker could not reserve that host socket because another process or container already binds it. Verify duplicate compose projects and stale containers, then free or remap the port.

Why does "driver failed programming external connectivity" appear with restart loops?

The runtime keeps retrying a container that fails at port-publish setup. Resolve the publish failure branch (host process, stale container/network, or compose mapping mismatch) before restart policy tuning.

Can restart: always fix a Docker restart loop caused by port conflicts?

No. restart: always only retries the same failing bind operation. Clear the conflicting port owner or mapping first, then keep restart policy for resilience only.

Docker Restart Loop + Port Is Already Allocated + Bind Address Already in Use: Fix Decision Flow (2026)

Published March 1, 2026 · 8 min read

Fix It With a Tool

Validate your port and compose mappings first

Use mapping checks before another restart attempt so you stop noisy retries and isolate the bind failure branch.

Open Compose Validator Open Docker Run Generator

Intent match: this guide is for failures that combine a docker restart loop with port is already allocated or bind address already in use errors. For broader startup crashes, see Docker Container Exits Immediately and Docker Restart Loop Decision Tree.

Single decision flow for three conflict branches
Verification commands after fix
FAQ

1. Single decision flow: choose one branch and clear the bind conflict

Branch A: Host-process conflict (non-Docker process owns the port)

Signals: host-level service is running (Postgres, Redis, Nginx, app dev server), and Docker publish fails immediately.

ss -ltnp | rg ':5432|:8080' || true
lsof -i :5432 -sTCP:LISTEN || true

Fix: stop the host process or remap container publish port (for example 5433:5432) and redeploy once.

Branch B: Stale container or network conflict

Signals: prior container still exists, project rename left orphaned resources, or a stale compose stack keeps the port reservation.

docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
docker compose ls
docker network ls

Fix: bring down the old stack, remove stale containers, then recreate cleanly.

docker compose down --remove-orphans
docker container prune -f

Branch C: Compose mapping conflict (duplicate or invalid port mapping)

Signals: duplicated host ports across services, wrong environment substitution, or mixed overrides map two services to one host socket.

docker compose config
rg -n '^\s*-\s*"?[0-9]+:[0-9]+' docker-compose*.yml

Fix: make host ports unique across services and environments, then run a fresh docker compose up -d --force-recreate.

2. Verify the fix before enabling aggressive restart policy

docker compose ps
docker logs --tail=80 <container_name>
docker inspect <container_name> --format '{{.State.Status}} {{.RestartCount}}'

Service state should be running with stable restart count.
The old bind error string should disappear from fresh logs.
Only after that, keep restart: unless-stopped or on-failure based on workload type.

3. FAQ

Do I need to reboot the host for "port is already allocated"?

No. In most cases, a precise owner check plus container cleanup resolves it without host reboot.

Can two compose projects safely share one host port?

No. One host socket can be bound once per protocol and interface combination.

What if the conflict is intermittent across deploys?

Audit deploy order and compose overrides. Intermittent conflicts are often caused by overlapping project names or reused host ports in parallel environments.