PortAura is a native macOS utility that shows which processes are listening on which ports, where they’re exposed, and what has changed since your trusted baseline. It helps you understand local services without digging through Terminal commands. Everything runs locally on your Mac.
I built PortAura because I kept running into the same question on my Mac: what is actually listening on this port, which process owns it, and is this something new?
Terminal tools can answer that, but the information is scattered and not always easy to read at a glance.
PortAura brings ports, processes, exposure scope, and baseline changes into one native Mac interface. A baseline change doesn’t automatically mean risk — it simply gives you a clear signal that something changed and is worth reviewing.
Everything runs locally on your Mac. No account, no cloud dashboard, and no unnecessary background service.
I’d really appreciate feedback from Mac users and developers on what would make this more useful.
appreciate that this stays local instead of shipping port/process data to a cloud dashboard - for a security tool that's the right default. curious how the baseline gets set initially though: is it a manual "snapshot now" action, or does it auto-baseline after first install, since a bad first snapshot (taken while something unwanted is already running) would make the whole diff useless.
Report
Maker
@galdayan Good question — PortAura does not auto-baseline on first install.
The baseline is only created when the user explicitly reviews and confirms the current listening state, and updating it later also requires confirmation. That’s intentional for exactly the reason you pointed out: I don’t want the first snapshot to be silently treated as trusted.
That said, PortAura is a change detector rather than a malware scanner, so if someone manually confirms a bad state, it would still become part of the baseline. Your point makes me think the first-baseline flow should probably make that trust decision even more explicit. Thanks for calling it out.
@efrem_lee that's a sensible tradeoff honestly - a manual confirm step is a better default than trusting whatever's running at install time. makes me think the confirm screen itself could show a quick "does this look normal" checklist (unexpected listeners, unfamiliar process names) rather than just a raw list, so the human doing the confirming has some help catching the bad state before it gets baked in as trusted.
Report
Maker
@galdayan That’s a really useful suggestion.
A lightweight “does this look normal?” step during the first baseline confirmation makes a lot of sense — especially surfacing things like unfamiliar processes or unexpectedly exposed listeners, without pretending PortAura is a malware scanner.
I like the idea of making that first trust decision more guided instead of showing only a raw list. I’m going to explore this for a future update. Thanks for the thoughtful feedback.
@efrem_lee makes sense, and honestly that's the right scope - a change detector that flags "this is new" is more useful long-term than a scanner trying to guess good vs bad on its own. good luck with the update.
Dial
appreciate that this stays local instead of shipping port/process data to a cloud dashboard - for a security tool that's the right default. curious how the baseline gets set initially though: is it a manual "snapshot now" action, or does it auto-baseline after first install, since a bad first snapshot (taken while something unwanted is already running) would make the whole diff useless.
@galdayan Good question — PortAura does not auto-baseline on first install.
The baseline is only created when the user explicitly reviews and confirms the current listening state, and updating it later also requires confirmation. That’s intentional for exactly the reason you pointed out: I don’t want the first snapshot to be silently treated as trusted.
That said, PortAura is a change detector rather than a malware scanner, so if someone manually confirms a bad state, it would still become part of the baseline. Your point makes me think the first-baseline flow should probably make that trust decision even more explicit. Thanks for calling it out.
Dial
@efrem_lee that's a sensible tradeoff honestly - a manual confirm step is a better default than trusting whatever's running at install time. makes me think the confirm screen itself could show a quick "does this look normal" checklist (unexpected listeners, unfamiliar process names) rather than just a raw list, so the human doing the confirming has some help catching the bad state before it gets baked in as trusted.
Dial
@efrem_lee makes sense, and honestly that's the right scope - a change detector that flags "this is new" is more useful long-term than a scanner trying to guess good vs bad on its own. good luck with the update.