Ports and conflicts in local development

A port is a number from 0 to 65535 that tells your machine which program should receive a connection. Normally only one program can listen on a given address and port, so a second dev server either fails to start or moves to another port by itself. To fix a clash, find the process that owns the port, decide whether it is yours to stop, then stop it politely or give your server a different port. To prevent clashes, give each project a fixed port and write the plan down once.

Updated

Why dev servers clash

A server binds an address and a port, then listens. Normally the operating system lets only one program hold that pair, so a second bind fails with EADDRINUSE. Defaults make a clash likely: Next.js, Nuxt, and Rails all default to 3000, and Django and Laravel’s artisan serve both default to 8000. The network port entry covers the number ranges and why TCP and UDP have separate port spaces. The ports index maps which tools share a default.

What a tool does when its port is busy

Tools react in three ways. Some move to another port without asking, so the server may not be where you configured it: Vite does this unless you pass --strictPort, and Next.js does it only if you did not choose a port. Some fail and exit, such as Django, Flask, and Rails. Angular asks in a terminal and exits with an error in a script. Read the URL your server prints before you open a browser tab.

Reading order

  1. The server will not start. Follow find what is using a port and free it, or let the port in use command generator write the commands for your system.
  2. Another device cannot reach it. Read localhost vs 127.0.0.1 vs 0.0.0.0, then the localhost and loopback address entries.
  3. You are setting up a stack. Give each service its own port with the local dev port planner before you write any config.
  4. One tool misbehaves. Open its page from the ports index, for example PostgreSQL.

Stopping it from happening again

Set each project’s port in one place, and make the tool fail instead of drifting where it supports that, as --strictPort does in Vite. In Node.js tests, listen on port 0 and read the port the operating system assigns.

Where Rig fits

Everything above works without Rig. Rig’s who_owns_port MCP tool finds the owner with lsof (netstat and tasklist on Windows), returns its process ID and command, and suggests a free port, and kill_port sends SIGTERM before SIGKILL. The Rig app also shows who owns a busy port and offers to reclaim it: see Common port conflicts and Ports, crashes, and reclaim.

Limits

A port that is free when you check can be taken before your server binds, so a check is a hint, not a lock. The command generator writes commands and never runs them, and the planner works only from the list you give it, so neither can see what is running on your machine.

Tools in this topic

Guides in this topic

Glossary terms in this topic

Port references in this topic

Knowledge base articles in this topic

Blog posts in this topic

Frequently asked questions

Why does my dev server say the port is already in use?

Another socket already holds that address and port. It is often an earlier copy of the same server still running in another tab, a background job, or a container. Find the owner and read its command before you stop anything.

Do two tools with the same default port always clash?

Only when both run at once on the same address. Some tools then move to another port by themselves and others exit, so check what your tool does when its port is taken. Give each project its own fixed port in its config so the result is the same every time.

Is it safe to kill whatever is using a port?

Not before you look. Read the command and its parent first. Your own earlier dev server is safe to stop. A database, a system service, or another user’s process is not yours to stop, so move your app to another port instead. Send a TERM signal first, and keep KILL for a process that ignores it.

Can a free port be taken before my server starts?

Yes. A port that is free when you check can be taken before your server binds, so a check is a hint, not a lock. In Node.js tests, listen on port 0 and the operating system assigns an unused port, which you read from server.address().port once the server is listening.

See how Rig fits in

Rig is a Mac app that starts, stops, and watches the processes in a project from one window. The knowledge base explains each part in plain language.

Related

Section links

https://userig.app/learn/ports-and-conflicts