---
title: "Discussion on \" Bind for 0.0.0.0:5432 failed: port is already allocated - find port clashes before you run docker compose up\" | Hashnode"
description: "Discussion on \" Bind for 0.0.0.0:5432 failed: port is already allocated - find port clashes before you run docker compose up\". Port is already allocated\" from Docker and EADDRINUSE from Node mean two things want one host port, and both are usually already written down in the repo. Why it happens, how to fix it, and a free VS Code extension that flags port clashes before anything starts."
url: "https://hashnode.com/posts/portclash-port-is-already-allocated-eaddrinuse/6acc530264de1b3fc30a96f5"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Bind for 0.0.0.0:5432 failed: port is already allocated - find port clashes before you run docker compose up](https://jaytank.hashnode.dev/portclash-port-is-already-allocated-eaddrinuse?utm_source=hashnode&utm_medium=feed)

Port is already allocated" from Docker and EADDRINUSE from Node mean two things want one host port, and both are usually already written down in the repo. Why it happens, how to fix it, and a free VS Code extension that flags port clashes before anything starts.

Oct 12 · 10 min read · jaytank.hashnode.dev  
Read the article

-   [#docker](https://hashnode.com/tag/docker)
-   [#vscode-extensions](https://hashnode.com/tag/vscode-extensions)
-   [#developer-tools](https://hashnode.com/tag/developer-tools)
-   [#web-development](https://hashnode.com/tag/web-development)
-   [#devops](https://hashnode.com/tag/devops)

## Written by

[JAY TANK](https://hashnode.com/@jaytank)

@jaytank

  
[View profile](https://hashnode.com/@jaytank)

Engineering insights on building and scaling modern software.

Cloud & Platform Engineer focused on building systems that scale and endure. I explore how infrastructure, automation, and engineering practices come together to support modern software teams.

## Responses 2

Markdown supported · ⌘↵ to post

[StackShortlist](https://hashnode.com/@veristria)

[Oct 17](https://hashnode.com/posts/portclash-port-is-already-allocated-eaddrinuse/6acc530264de1b3fc30a96f5/comment/6ad339a119313ca07cff7a02)

The Vite point is the one that bites quietly. Without server.strictPort it just moves to 5174, and the only symptom is an OAuth callback or CORS error that looks unrelated. Setting strictPort: true in shared repos turns that into a loud failure, which is easier to debug. Binding databases to 127.0.0.1 is also a good default even when there's no clash, since nothing outside the machine needs to reach a dev Postgres.

[JAY TANK](https://hashnode.com/@jaytank)

[Oct 28](https://hashnode.com/posts/portclash-port-is-already-allocated-eaddrinuse/6acc530264de1b3fc30a96f5/comment/6ad339a119313ca07cff7a02#reply-6ae16ecd434ed7bc00025c59)

Thanks, you've put your finger on exactly the failure that hurts most. The 5174 fallback is the worst kind of bug, because the error you see (an OAuth redirect mismatch or a CORS block) points somewhere completely different from the real cause.

PortClash already covers both points:

Vite: when a Vite dev server's port clashes with something else, the finding says Vite will silently move to the next free port unless server.strictPort is true. It also checks whether strictPort is already set in vite.config or passed as --strictPort, so you know which behaviour you'll get.

Databases: if a compose service publishes a database port on all interfaces ("5432:5432" with no host IP, which means 0.0.0.0), it gets flagged even when nothing else is using that port. It's reachable from your network, and Docker's published ports can bypass host firewall rules like ufw. The fix is to bind it to 127.0.0.1:5432:5432.

I agree on strictPort: true as a default for shared repos. A loud "port already in use" takes ten seconds to fix. A quiet move to 5174 can cost an afternoon.