Why I built PortPilot

You start a frontend. Then an API. Then yesterday’s debugger is still on :9229. “Port already in use.” Terminal. lsof. A PID. The wrong kill. Again.

That is not a rare bug. It is the daily cycle: ports, a JSON blob, a local database. Every developer already has a tool for each piece. I built PortPilot because I was tired of opening four of them before the stack was even running.

What it replaces

lsof -i :3000 works. So does Activity Monitor. You still do it after lunch, and again when two Vite servers collide. You copy a PID and hope it is the right process. CPU meters do not say “this is the dashboard repo.”

PortPilot is the tray utility for that loop:

Live ports, with the project folder on the row
Kill, restart, or open localhost from the row — no PID paste
Clipboard, JSON, JS Playground, Time Bench, and local DBs in the same window
Cmd + Option + P from anywhere, so it feels like part of the OS

It stays in the menu bar. No login. No cloud. The data is already on the laptop.

Three rooms, one desk

The afternoon is rarely “only ports.” You kill a process, copy an error, check local Postgres. PortPilot is three rooms, not three apps:

Cmd + 1 / 2 / 3 switch rooms. Cold start always opens Ports. Each room remembers the last screen you used.

It is not a DBA studio and not a cloud IDE. It is the all-in-one I leave running.

Next: the actual features, and a playground you can drive — kill a port, open Text & Data, inspect a connection.