What’s running on port 54321 on my Mac?

Check what’s on port 54321

lsof -nP -iTCP:54321 -sTCP:LISTEN

You’ll see com.docker.backend (Docker Desktop) or OrbStack, not Supabase itself, because the CLI runs everything in containers. To see the whole block at once:

lsof -nP -iTCP:54320-54330 -sTCP:LISTEN

Then ask the CLI, from the project folder:

supabase status

To find which project owns a running stack when you don’t know the folder, list the containers. Their names end in the project_id from config.toml:

docker ps --format '{{.Names}}' | grep supabase

With Stat Space: statspace port 54321.

Stop it

supabase stop

Run it in the project folder. Your local data is kept in Docker volumes; add --no-backup only if you want a clean database next time. Don’t kill com.docker.backend to free the port, because that stops every container you have.

Change the ports

Each service has its own section in supabase/config.toml:

project_id = "acme-2"

[api]
port = 55321

[db]
port = 55322

[studio]
port = 55323

[inbucket]
port = 55324

Restart with supabase stop && supabase start, and update SUPABASE_URL in your app’s .env. Changing project_id matters too: it’s what keeps the two stacks’ containers and volumes apart.

Who can reach it

Docker publishes these ports on your Mac, and the local stack uses well-known demo keys and the postgres password. Check lsof: on some setups the bindings show *:54321 rather than 127.0.0.1. On shared networks, that means anyone nearby can query your local API or connect to Postgres on 54322. Stop the stack when you’re not using it. See dev server exposed to the network.

Seeing it live

With Pro, Stat Space maps 54321 and its neighbors to the Supabase containers behind them instead of a row of com.docker.backend entries. The free Ports tab still shows every listener and flags ones bound to all interfaces.