Processes, ports, and localhost

Why this matters

From Week 6 onward you will start a server, look at it in a browser, and stop it again every single day. Today you learn what that actually is: a process you started, listening on a port, reachable at localhost. Get this right now and "why is nothing loading?" becomes a two-minute check. You will also meet the error that stops nearly every beginner cold — a port already in use — and fix it deliberately instead of by restarting the computer.

A program is a file; a process is a running thing

A program is a file sitting on disk, not running. On Day 2 you installed Node.js — that put a program on your machine, and it did precisely nothing until you typed node --version.

A process is one running instance of a program. When you press Enter, the operating system loads the program into memory, gives it its own workspace, and assigns it a number called a PID (process ID). That process exists, uses memory and CPU, and can be inspected or stopped.

Most commands you have run start a process, do their work, print, and exit within milliseconds. A server is different: it starts and stays running, waiting. That is why your terminal does not return to the prompt after you start one — the process is still there, holding the terminal.

You can see running processes:

ps aux | grep node

The | is a pipe: it sends the stdout of ps aux into grep, which keeps only matching lines. (PowerShell: Get-Process node.)

localhost: the computer talking to itself

localhost is a name that always means "this computer" — whichever computer you type it on. It resolves to 127.0.0.1 (or ::1 in IPv6), the loopback address. Traffic sent there never touches your network card, never reaches your router, and never leaves the machine. That is what lets you develop offline: browser and server on the same laptop, request looping back internally.

One consequence worth knowing: nobody else can reach your localhost. Send a colleague http://localhost:3000 and they see their own machine's port 3000, not yours.

Ports, and why they collide

Your computer has one address on the network but may run many programs that want to receive traffic. A port is a number from 1 to 65535 that says which program an incoming message is for. The address gets the message to the machine; the port gets it to the right process.

A URL shows this directly:

http://localhost:3000
 └─┬─┘  └───┬───┘ └┬─┘
scheme    host   port

Some ports are conventional: 80 for HTTP, 443 for HTTPS. Browsers assume those when you type no port, which is why everyday web addresses show none. Development servers use high, unclaimed numbers — 3000, 5173, 8080 are common.

The rule that causes all the trouble: only one process can listen on a given port at a time. Start a second on the same port and it fails with EADDRINUSE — "address already in use". Not a bug: the operating system refusing to make delivery ambiguous.

Stopping a process

Because a server runs until told otherwise, you need a way to tell it. In the terminal where it is running, press Ctrl+C. That sends SIGINT, an interrupt signal — a message the operating system delivers to the process asking it to stop. It shuts down and your prompt returns. Closing the browser tab does nothing: the browser is only a client.

Walkthrough: start it, prove it, break it, stop it

Create the folder:

cd ~/fullstack-journey
mkdir localhost-demo
cd localhost-demo

Then create server.js in your editor with exactly this:

const http = require("node:http");

const server = http.createServer((request, response) => {
  response.end("Hello from a process on my own machine\n");
});

server.listen(3000, () => {
  console.log("Listening on http://localhost:3000");
});

You do not need to understand every line yet; Week 6 covers node:http properly. What matters today is 3000 — the port this process is claiming. Start it:

node server.js

Listening on http://localhost:3000

Your prompt does not come back. That is the point: the process is alive and waiting. Open http://localhost:3000 in your browser and you will see the message. That round trip stayed entirely inside your machine.

Now open a second terminal and look at who holds the port:

lsof -i :3000 -P

COMMAND    PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
node     48213  you   20u  IPv6 0x62a4bd2e5f21a3b1      0t0  TCP *:3000 (LISTEN)

The -P flag keeps the port numeric instead of showing a service name. There is your process, its PID, and the port it holds. (Windows: netstat -ano | findstr :3000.)

Now cause the collision on purpose, in that same second terminal:

node server.js

Error: listen EADDRINUSE: address already in use :::3000

Node buries that line in a stack trace; it is the part that matters. Read it as: the port is taken, by the process you already started.

Now go back to the first terminal and press Ctrl+C. The prompt returns. Refresh the browser tab:

This site can't be reached — localhost refused to connect. ERR_CONNECTION_REFUSED

"Refused" is precise: the machine answered, but nothing is listening on 3000 any more. Confirm from the terminal — lsof -i :3000 -P now prints nothing at all.

Using AI today: tutor mode

Today's mode is tutor. A tutor-style request asks the AI to explain the concept, give a small example, then let you attempt it yourself. That ordering is the whole difference — a request that opens with "build the whole thing" hands you something you cannot debug or defend.

Your turn

1. Repeat the walkthrough in ~/fullstack-journey/localhost-demo without looking back for the commands.
2. Change the port in server.js from 3000 to 4000, restart, and load http://localhost:4000. Confirm http://localhost:3000 no longer answers.
3. With the server running, run lsof -i :4000 -P in a second terminal and record the PID.
4. Trigger EADDRINUSE deliberately and record the exact error text.
5. Stop the process with Ctrl+C and prove it is gone twice: the browser refuses to connect, and lsof prints nothing.
6. Write localhost-notes.md defining, in your own words, process, localhost, port, and stop signal — each with the evidence you personally saw.

Common pitfalls

• Thinking the terminal is frozen. It is not; a foreground server holds it by design. Open a second terminal rather than killing the first.
• Closing the tab and assuming the server stopped. Only Ctrl+C in the running terminal stops it.
• Sharing a localhost URL. It resolves on their machine. Nobody can reach your loopback.
• Panicking at EADDRINUSE. It says one thing: something already owns that port. Find it with lsof -i :3000 -P, stop it, or pick another port.

Verify it yourself

Open today's reference, the Node.js Introduction, and find where it describes how Node.js runs JavaScript outside the browser.

1. Does the page agree with this lesson's claim that a Node server is a long-running process rather than a command that finishes? Find the wording.
2. This lesson used require("node:http"). Find how the Node docs write module imports and note whether they prefer a different form — then add what you found to localhost-notes.md.