Bind for 0.0.0.0:15432 failed: port is already allocated — another container already publishes that host port, so Docker will not give it to a second one. Find the holder with docker ps --filter publish=<port>, then either stop it or publish your container on a different host port.

Then create the failed container again rather than just starting it. On this machine, a container that had hit this error later started without its published port, and nothing could connect to it.

The error

$ docker run -d --name fix3-dpg-porta -e POSTGRES_PASSWORD=dev-only-password -p 15432:5432 postgres:18
12838c96fd56a4d9e83ded4c7ed1ddd1034aea7542bb1f0d4a59934491290bad
$ docker run -d --name fix3-dpg-portb -e POSTGRES_PASSWORD=dev-only-password -p 15432:5432 postgres:18
86f98c3894680c1b211d4c01552a15528db0f0d3a28c9d5483dfda00a0091e7d
docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint fix3-dpg-portb (acf9ff516cb378c739f36dacbeae65198ffdfc473a67c13bf67e14113dae6599): Bind for 0.0.0.0:15432 failed: port is already allocated

Docker Compose, with "15432:5432" under ports:, stops at the same place:

 Container fix3-dpg-db-1 Starting
Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint fix3-dpg-db-1 (06ce54ac76a14faea62936758eef9ba08790af88eff330fa520f7ebf4776cdec): Bind for 0.0.0.0:15432 failed: port is already allocated

Why it happens

-p 15432:5432 asks Docker to forward host port 15432 to port 5432 inside the container. The container side is private to each container, so any number of PostgreSQL containers can listen on 5432 inside. The host side is shared: the first container to publish 15432 owns it, and Docker refuses the second while it sets up the container's networking. The holder can be any running container: an earlier run of the same command, or another project's compose file that maps the same port.

The failed container is not thrown away. docker ps -a listed fix3-dpg-portb as Created, and Compose left fix3-dpg-db-1 the same way. That leftover is what causes the second surprise below.

The fix

Find out who holds the port:

docker ps --filter publish=15432 --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'
NAMES            IMAGE         PORTS
fix3-dpg-porta   postgres:18   0.0.0.0:15432->5432/tcp, [::]:15432->5432/tcp

To run both, remove the failed container and publish another host port:

docker container rm fix3-dpg-portb
docker run -d --name fix3-dpg-portb -e POSTGRES_PASSWORD=dev-only-password -p 15433:5432 postgres:18

To free the port instead, stop the holder and recreate the Compose service:

docker stop fix3-dpg-porta
docker compose -p fix3-dpg up -d --force-recreate

Both ended with the port listed in docker ps and a psql connection through it. The recreate is the important part. A plain docker compose up -d after stopping the holder started the leftover container with 5432/tcp and no host port; docker inspect showed the binding configured but "5432/tcp":[] in effect, and connections were refused. docker start on the failed docker run container did the same, even after a stop and start. Removing it and creating it again fixed both.

How it was reproduced

Docker Desktop 4.91.0 (engine 29.8.0, Compose v5.5.1) on Windows 11, image postgres:18 (18.4). Host port 5432 was taken by a PostgreSQL installed natively on this machine, so the test used 15432 and 15433; the message carries whichever host port you published. Two containers published 15432, then a one-service compose project did the same. Every fix was checked with psql from a client container through host.docker.internal. Names beginning fix3-dpg- are this test's own containers; use yours.

Frequently asked

How do I find which Docker container is using a port?
Run docker ps --filter publish= followed by the host port number. It lists the running container that publishes that port, with its name and port mappings, so you can stop it or change your own mapping.
Can two Docker containers use the same port?
Inside the container, yes: each container has its own network, so two PostgreSQL containers can both listen on 5432. On the host, no: publish them on different host ports, for example 15432:5432 and 15433:5432.
Why does my container have no published port after fixing port is already allocated?
The container that failed was left in the Created state. On Docker Desktop 4.91.0, starting it later ran it without its host port. Remove it and create it again, or use docker compose up -d --force-recreate.

More decoded errors in the Fixes category. If no container holds the port and Docker on Windows still refuses it, the message is ports are not available.