Should I bind my Heroku app to process.env.PORT or a fixed port for local development?

Short answer

Read process.env.PORT first, with a local fallback. Never hardcode a fixed port as the only option.

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`Listening on ${port}`));

On a dyno, Heroku always sets $PORT, and its router sends traffic only to that port. If your process binds to anything else — or fails to bind within the startup window — the dyno is killed with an R10 boot timeout error. Locally, $PORT is usually unset, so the fallback keeps the same code starting cleanly on your machine.

Likely explanation vs. confirmed facts

Confirmed: the dyno's assigned port is dynamic and can change between restarts and deploys, so no fixed value will ever match it. The fallback branch only ever executes off-dyno.

Likely but worth verifying in your case: if your app boots locally but crashes on every deploy, the cause is almost always either ignoring $PORT or binding to 127.0.0.1. Heroku's router must reach your process from outside the container, so bind to 0.0.0.0 (the default in most frameworks when you omit the host). Localhost-only binding works on your laptop and fails silently on dynos.

Verifying the fallback behaves like the dyno port

1. With PORT unset, start the app and confirm it lands on your fallback: curl http://localhost:3000.
2. Prove the env var takes precedence: PORT=5000 node server.js, then curl port 5000.
3. Run heroku local. It reads your Procfile and .env; adding PORT=5000 to .env makes the app see the same variable it would on a dyno, exercising the identical code path.
4. Deploy and watch heroku logs --tail for a clean startup with no R10, then hit the herokuapp.com URL.

Drawbacks of a specific fallback like 5000

On the dyno: none. Each dyno is an isolated container, $PORT is always set by the platform, and your fallback value never executes there — it cannot interfere with other dyno processes.

Locally: 5000 is the conventional default for heroku local and foreman-style runners, but on macOS it collides with the AirPlay Receiver service, producing confusing "address in use" errors. If you hit that, either disable AirPlay Receiver (System Settings > General > AirDrop & Handoff) or pick a different fallback such as 3000. Also avoid committing a .env containing PORT if teammates use different local ports — .env is local-only config and is typically gitignored.

One diagnostic detail that would change this advice: if your app still fails on deploy despite reading $PORT, share whether you pass an explicit host to listen() — a 127.0.0.1 bind is the next most common culprit.