Portero

Know exactly what's running on every port of your Mac

Open Source

Developer Tools

GitHub

Visit WebsiteSee on Product HuntCloudflare Pages ⧉

The "which node, from which project" problem is exactly why raw lsof never stuck for me — mapping a port back to a working directory is the useful part, not just listing PIDs. Two implementation questions: to enumerate every process's ports and to add a firewall block, does Portero need a privileged helper/root, or does it stay inside the user sandbox? And does a blocked port persist across reboots via pf rules, or only for the current session?

the visibility ceiling is worth spelling out — unprivileged lsof only sees sockets owned by your own uid, so a root daemon listening on a port stays invisible until the app escalates. for a dev tool that's fine. tagged as security software, that's exactly the port you'd want to see.

Are you planning to support deep Docker integration where Portero queries the local Docker socket? If we could resolve a generic docker-proxy process down to the exact container name and Docker Compose service, this would instantly become a must-have tool for local microservice debugging.

Congrats on the launch! I’m the non-technical guy who vibe-codes with AI, so “address already in use” errors are pure fear for me, I never know which process is safe to touch. The plain-language part is exactly what I need. My question: when I go to kill a process, does Portero warn me if it’s something system-critical? Translating “sharingd” to “AirDrop and sharing” is great, but a “killing this will break X” heads-up is what would make me trust it enough to click the button.

Turning port management into a visual, one click experience is such a smart touch, especially building on the native macOS firewall instead of reinventing it.

@ctresb It polls every few seconds by default, but what's the battery/CPU tradeoff on a laptop with that running constantly? would be nice to know if there's an on demand mode, or if the polling stays cheap regardless of how many ports are open

The plain-English process identity is the feature. “node on 3000” is technically true but not enough to decide whether killing it is safe. Project path, launch source, and last command/context would make this especially useful for Mac dev machines with several half-running projects.

The native Mac feel is spot on, especially surfacing the owning process right next to each port instead of burying it in a menu. Killing whatever's hogging a port in two clicks is exactly the kind of fix I've wanted for years.

@C3B Congrats on the launch! 🎉 Loving the clean macOS native UI and built-in firewall blocking.

Question on state tracking: is Portero strictly showing live snapshots of active listeners, or is there any background logging to help catch ephemeral/ghost background processes that grab a port and crash before you can inspect them?

How do you handle cases where a process is holding onto a port but isn't actively using it, and what's the criteria for suggesting to kill a process?

The context labels are the actual product here — "node" vs "Vite dev server, project storefront" is the difference between killing the right process and killing your teammate's demo. Curious how you infer the project context — walking up from the process cwd looking for package.json, or something smarter? Open source is appreciated, will poke around the repo.

the plain-english translation is the actual feature here, lsof telling you 'node' on port 3000 is technically correct and completely useless. one thing I didn't see mentioned - does it handle docker-proxy processes sanely? that's usually where this kind of tool falls apart for me, a container's port mapping shows up as some generic docker-proxy pid and you're back to guessing which compose project it belongs to

The ability to open local servers directly from the app is a nice touch. Small workflow improvements like that often end up being the features people use every single day without even thinking about them.

A developer I know constantly switches between projects and ends up with old servers still running in the background. I think the would save them a lot of time, especially when debugging local development issues. I'll definitely share it with them.

This looks super handy for tracking down port conflicts. One thing I'd love to see is a way to save profiles or groups of ports I'm monitoring for specific projects, so I don't have to keep an eye on a long list manually every time I switch contexts.

Would love to see a quick right-click option to copy the PID or port number straight to the clipboard, since I often need to paste those into terminal commands when cleaning up stuck processes.

Hey congrats on the launch! Q - Does it keep a log of what was running on a port historically, or is it strictly a live snapshot? Thinking about those annoying edge cases where a background task grabs a port and crashes before you can even catch what it was