PortPal turns a port list into a kill button and a topology map

The EADDRINUSE error, rendered as a table instead of a hunt

PortPal starts from a very specific frustration. The README opens with the raw error a Node developer sees:

Error: listen EADDRINUSE: address already in use :::3000

The complaint that follows is that something is squatting on the port and you are hunting for PIDs and copy-pasting kill commands. The tool's premise is that this loop should not exist.

The dashboard lists every listening port on the machine with the process name, the PID, the current connections, a framework detection and a project identification. The project identification is the part that goes beyond a netstat replacement. The README says PortPal crawls for package.json, Cargo.toml or go.mod to name the running servers, so a port is labelled with the project it belongs to rather than just a process name.

The action is a single hover and a click on a cross to kill the process, and a separate restart button appears for processes PortPal knows how to start. Processes that have died show a stopped badge with a persistent restart button rather than vanishing from the list, which is a small touch that matters when you are cycling a dev server.

Framework detection is a port number table, and that is the whole mechanism

The detection engine is straightforward, and the README is candid about it. Framework detection recognizes React, Vite, Angular, Django, Node and others by their default ports, and the table in the README lists them with a color for each: 3000 for React, 4200 for Angular, 5173 for Vite, 4000 for Node.js, 8000 for Django, 8080 for HTTP, 5432 for Postgres, 6379 for Redis, 3306 for MySQL, 27017 for MongoDB and 1420 for Tauri.

That is a hardcoded mapping, and it is worth being plain about the consequence. A framework running on a non-default port will not be recognized, and a database on a non-standard port will show up as an unclassified port. The roadmap lists expanding supported framework signatures as a work in progress, which confirms the table is the extension point.

The payoff is that the colors carry through the whole interface, including the topology graph, where the README describes framework-colored nodes. So the same classification that names a port also decides how it looks in the map, which is why a small table of eleven entries can carry so much of the visual design.

The D3 port map and its drag-and-collide simulation

The interactive port map is the feature the README calls the crown jewel. It is a D3.js force-directed graph that shows how your services are communicating, and it is the reason this is more than a nicer netstat.

The graph is a physical simulation rather than a static diagram. The README describes a drag and collide simulation for physical manipulation, scroll to zoom and navigate, and node caching with real-time updates without screen flickering. That last detail is the one that matters for usability, since a graph that re-lays-out on every refresh is unusable and one that never refreshes is a lie.

Connections carry metrics, so you can see not just which services talk but how much. Combined with the traffic sparklines described in the v0.2 notes, the map becomes a way to spot a service that is unexpectedly chatty.

The port map also inherits the framework colors and the dev versus system separation, so nodes belonging to your own projects are visually distinct from operating system processes, which is the difference between a useful topology and a wall of sockets.

A system tray app that logs while the window is closed

PortPal lives in the system tray rather than insisting on a full window. The README describes a traffic light icon that immediately alerts you to conflicts and statuses, and a background thread that quietly builds a historical log of all backend activity while the window is closed.

That background behaviour is what makes the v0.2 feature list work. The historical event logging page tracks every process start, stop and connection spike with timestamps and framework contexts, and the log is only useful if it covers the period when you were not looking at the window. A tool that only records what happens while it is open is a snapshot; this one is a journal.

The v0.2 section of the README also describes a move from a simple port list to what it calls a Developer Command Center. The additions are traffic sparklines as animated SVG mini-charts embedded in the metrics, categorized services grouped into cards by project and framework, and a filter between dev frameworks and other system apps, complete with a Kill All panic button.

The Kill All button deserves a note. It is the sort of control that is genuinely useful when six dev servers are fighting over memory, and the sort of control that is worth being careful with, which is why the categorization and filtering exist alongside it.

Building it: Node 18, Rust 1.70 and the Tauri CLI

Prebuilt installers are the normal route, and the README's download table lists a .msi installer and .exe setup for Windows, .dmg builds for Apple Silicon and Intel on macOS, and .deb and .AppImage for Linux.

Building from source needs three tools. Node.js at version 18 or higher, Rust at 1.70 or higher, and the Tauri CLI at v2, which the table notes is included.

The development loop is a clone and two commands:

# Clone
git clone https://github.com/wisher567/Portpal.git
cd portpal

# Install & Run
npm install
npm run tauri dev

The README notes that the app launches with Vite HMR, so you can edit React components and see changes instantly alongside the Rust backend watcher. That is the standard Tauri two-process development setup, and it is worth knowing because editing the frontend and the port scanning engine are two different activities happening at once.

The package.json confirms the shape of the project. The portpal package is marked private with version 0.2.0, the type is module, and the scripts are dev, build, preview and tauri. The runtime dependencies are the Tauri API and the dialog and opener plugins, d3, howler for audio, html2canvas for image capture, and React with React DOM.

Rust backend, React frontend, D3 visualization

The architecture table in the README is a compact description of the whole project. The runtime is Tauri 2 with a Rust backend and a native webview, the frontend is React 19 with TypeScript and Vite 7, visualization is D3.js v7 with a force-directed graph simulation, and styling is vanilla CSS described as custom glassmorphism.

The port engine is the part to look at. The README calls it a custom native scanner built on sysinfo plus standard OS tools, which is a meaningful choice. sysinfo gives the process information and the standard OS tools cover what a library cannot reach, and it means the tool is not simply shelling out to netstat and parsing its output. The README is explicit that PortPal is not just a basic netstat wrapper.

The data pipeline is described more technically than the rest: a singleton thread-safe event logger built with lazy_static. That is the machinery behind the historical log, and it also explains the background thread that keeps logging while the window is closed.

The repository layout mirrors this. There is a src directory for the React frontend, src-tauri for the Rust side, an assets directory holding the hero image and the demo gif, a public directory, index.html, vite.config.ts and separate tsconfig files for the app and the node build.

MIT licensed, no tagged releases, and a last push in April 2026

The licence is the MIT License, with the LICENSE file at the repository root. The README says contributions are heavily welcomed and lays out the standard fork, branch, commit, push and pull request flow, with the branch example given as git checkout -b feat/amazing-feature.

On maintenance, the picture needs stating accurately. The repository is not archived, and the last push was on 2026-04-12. The repository has no GitHub releases, while package.json reads version 0.2.0 and the README describes what is new in v0.2. That combination means the version number lives in the manifest rather than in tags, and the README's download table points at the releases page for the .msi, .exe, .dmg, .deb and .AppImage files, so it is worth confirming that the build you download matches the tree you would clone.

The roadmap lists four items: expanding supported framework signatures, theme customization and light mode support, Homebrew and Winget verification, and expanding unit and integration tests. The last one is the honest signal about the project's maturity. A port scanner that kills processes and watches traffic has obvious places where a regression would be quiet, and the acknowledgement that test coverage is thin is the kind of thing to weigh when you decide whether to run it on a machine with work on it.

Editorial conclusion

PortPal is worth adopting for a developer or small team running several dev servers at once, for anyone who has lost time to an EADDRINUSE error, and for people who want to see the shape of their local service dependencies rather than a list of sockets. It is the wrong tool for a server, for a container, and for anyone who would rather not install a desktop application with the ability to terminate processes on their machine. Before relying on it, check the release download for your platform, since the README links installers to the releases page while the repository has no tagged GitHub releases, and note that the last push was on 2026-04-12, so newer framework signatures may not be recognised.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. wisher567/Portpal on GitHub