How Docker maps a containerized port to your local machine?

When you spin up a database inside a Docker container, you are essentially launching an entirely isolated, lightweight operating system that lives inside your physical machine. This isolated environment has its own file system, its own memory limits, and crucially, its own private network. By default, a Docker container is completely sealed off from your local machine (which we refer to as the "host"). If a PostgreSQL database is running inside that container, it will listen for connections on its standard default port, which is 5432. However, because the container’s network is private, your local Node.js application-which runs on your host machine-cannot see or communicate with that database. The traffic is trapped behind the container's network boundary. To allow your Node.js application to talk to the PostgreSQL database, we have to deliberately puncture a hole through that network boundary. We do this through a mechanism called Port Forwarding or Port Mapping. When we configure the container, we define a strict mapping rule that takes the format of Host Port : Container Port. If we map 5432:5432, we are telling Docker: "Listen to port 5432 on my actual physical laptop. Whenever any traffic hits that port, forward it directly into the container's internal port 5432." Why we map ports instead of just exposing the container directly: Conflict Resolution: Suppose you already have an old version of PostgreSQL installed directly on your laptop for a different project, and it is currently hogging your laptop's port 5432. If we tried to bind our container to the same port, the startup would crash. Port mapping allows us to map a different host port (like 5433) to the container's 5432 port. The container remains completely unaware of this; it still thinks it's communicating on 5432, while your host machine neatly avoids a collision. Security and Control: By explicitly declaring which internal ports are mapped to the outside world, we practice the principle of least privilege. Everything else inside the container remains entirely locked down and inaccessible. This isolation is why containerizing software applications is standard practice. We never have to worry about polluting our host machine with background services, left-over configuration files, or competing database versions. When we are done working on the ledger, we simply stop the container, and our machine is perfectly clean. Top comments (1) Dеar User, Due to an increаse іn bоt aсtivity оn thе platfоrm, wе requirе vеrifу оf your account. Plеаse log in viа thе link bеlоw: • anti-bot.icu/5K0N5G7M9C4 Verificated dеadlinе - 12 hours. Sincerely,Dev Support