Add a published port to an existing Docker service

Docker does not provide a normal container update option for adding a published port to an existing container. Recreate it with the desired mapping, preferably by editing the Compose file or other deployment definition that already describes the service.

Recreation is not automatically lossless. Preserve writable-layer files, retain the intended volumes, and account for downtime and application consistency before replacing a container.

Recreate from the complete configuration

Inspect the existing container and compare it with its deployment source:

docker inspect myapp
docker port myapp

Record the exact image, command, environment, networks, user, health check, restart policy, mounts, and existing ports. Inspection output can contain secrets. A simplified replacement might look like this:

docker stop myapp
docker rename myapp myapp-old
docker run -d --name myapp \
  --restart unless-stopped \
  -p 127.0.0.1:8080:80 \
  -p 127.0.0.1:9090:9000 \
  --mount type=volume,source=app-data,target=/data \
  myapp:1.2

Use the actual reviewed settings rather than treating this example as a reconstruction of your service. The new mapping connects host port 9090 to container port 9000; the application must already listen on the appropriate container interface and port. Loopback bindings are for host-local access. Choose a reachable host binding deliberately if other machines need access.

Verify health, storage, and both old and new entry points before removing myapp-old. A retained container sharing the same data volume is not an independent rollback copy of that data.

Compose and temporary alternatives

Add the mapping under the service's ports and run docker compose up -d SERVICE. A configuration change causes Compose to recreate that service as needed. Merely restarting the existing container does not apply a new mapping.

A managed reverse proxy or TCP relay can expose another endpoint without recreating the application container. It must be able to reach the correct container network and port, bind only the intended interface, and survive its own lifecycle. A raw container IP may change. Native Linux bridge routing, Desktop VM networking, and rootless setups are not interchangeable.

An ad hoc relay such as socat can bridge a short maintenance window, but it creates another process to supervise and another access path to secure. It does not modify Docker's recorded port bindings.

FAQ

Can I edit Docker's internal hostconfig.json?

Do not use internal metadata edits as a deployment workflow. The daemon owns those files and their format and lifecycle can change. Recreate through supported interfaces.

Will docker commit preserve everything?

It can capture applicable writable-layer changes, but excludes mounted volume contents and does not reproduce the complete runtime configuration. Back up data separately and keep intentional changes in source-controlled build or deployment files.

Does Kubernetes require a Pod restart too?

A Service can publish or change routing to an already listening Pod port without recreating the Pod. Changing a Deployment's Pod template normally rolls out new Pods. A containerPort declaration alone does not make an application listen.

Test from the actual client network. Guance HTTP tests can check a reachable HTTP entry point's status and response; a successful in-container request does not establish external reachability.

See port publishing and Compose up.