PortKiller: A Menu Bar Port Manager That Also Drives kubectl port-forward
A powerful cross-platform port management tool for developers. Monitor ports, manage Kubernetes port forwards, integrate Cloudflare Tunnels, and kill processes with one click.
At a glance
- What is it?
- PortKiller is a Swift and SwiftUI desktop app for macOS 15.0+ and Windows 10+ that lists listening TCP ports, kills the owning process, and keeps kubectl port-forward sessions alive. It is a convenience wrapper over lsof, netstat and kubectl rather than a new networking primitive, and its value depends on whether you want those commands behind a click.
- Who is it for?
- Adopt PortKiller if you already run kubectl port-forward sessions by hand and want auto-reconnect plus a menu bar list instead of a terminal window per tunnel, and if your machines are macOS 15.0+ or Windows 10+. Skip it on older macOS, on Linux, or if you need scripted port cleanup in CI, where lsof -ti:PORT | xargs kill does the job without a GUI.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 54 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The port conflict that eats twenty minutes a day
The problem is narrow and familiar. A dev server fails to bind because something already holds port 3000, and finding the holder means running lsof -i :3000, reading a PID, then killing it. On macOS the same ritual repeats for Postgres on 5432, a stale Rails server, or a Docker proxy. PortKiller puts the discovered listening TCP ports in one list and offers one-click termination with both graceful and force kill paths, per the README feature list. The audience is individual developers on a laptop or workstation, not platform teams. There is no server component, no agent, and no remote management. The README frames the whole product around a menu bar icon on macOS and a system tray app on Windows, which tells you the intended usage pattern: glance, kill, move on.
What the app actually does under the UI
The repository is Swift-first, with a platforms/macos directory holding the macOS target and its Resources folder, and the README states the Windows build ships as a separate native UI rather than a shared cross-platform toolkit. Port discovery is described as auto-discovery of all listening TCP ports, with a configurable auto-refresh interval, search and filter by port number or process name, and smart categorization into Web Server, Database, Development and System buckets. The categorization is a labeling layer over whatever the OS reports; the README does not describe a heuristic, so treat the bucket names as presentation. Kubernetes support is the more interesting mechanism: the app creates and manages kubectl port-forward sessions, auto-reconnects when the connection drops, and keeps connection logs with status monitoring plus notifications on connect and disconnect. That means PortKiller is supervising a child process and restarting it, which is genuinely more than a port list. Cloudflare Tunnel support is thinner in the material: the README promises viewing and managing active tunnel connections and quick access to tunnel status, with no detail on how the tunnel is started or authenticated.
Installing on macOS and Windows
macOS installs through a Homebrew cask: brew install --cask productdevbook/tap/portkiller. The manual path is a .dmg from the GitHub Releases page. Windows has no package manager path in the README; you download a .zip from Releases and extract it. The stated floor is macOS 15.0+ and Windows 10+, which is a real constraint rather than boilerplate: macOS 15.0 rules out anyone pinned to an older major release, and there is no Linux build despite the cross-platform framing. The README documents no configuration file, no environment variables, and no CLI flags. Every setting named in the feature list, the refresh interval, favorites, watched ports, search, lives in the app UI. For a tool whose job is process termination, that is worth noting: there is no documented way to declare your standard ports as code and check it into a repository, so a team cannot share a PortKiller configuration the way it would share a docker-compose file.
Killing processes is the part that can go wrong
The README offers graceful and force kill as two options but does not say which signal each maps to, and that gap matters. A graceful kill of a database process and a force kill of the same process have different consequences for open transactions and on-disk state, and the app presents them as two buttons on the same row. There is also no described safeguard against killing a process you did not start. The categorization into System ports implies the app can see processes owned by the operating system or by other users, and if the list includes them, a misclick is not recoverable by restarting your dev server. Watched ports with notifications is the closest thing to a guardrail, but the README does not explain what a watched port does beyond notifying. This is the case where the tool is wrong: if you need an audit trail of who killed which process, or you want termination gated behind a policy, a GUI menu bar app is the wrong layer. A wrapper script with explicit PIDs and logging is the better fit.
Where it sits against the tools you already have
The honest comparison is not another GUI. It is the shell. On macOS and Linux, lsof -ti:3000 | xargs kill -9 resolves a stuck port in one line, is scriptable, works over SSH, and appears in your shell history. PortKiller's advantage is statefulness: the Kubernetes auto-reconnect and the connection logs are things a one-liner cannot do, because they require a long-lived supervisor watching a kubectl child process. So the split is clean. For plain port cleanup, the shell wins on every axis except discoverability, since you have to know the port number first. For port-forward sessions that drop when your laptop sleeps or your VPN blips, the app is doing work you would otherwise script yourself with a retry loop. Cloudflare Tunnel management sits awkwardly between the two: cloudflared already runs as a daemon with its own status output, and the README does not explain what PortKiller adds beyond a status view.
Maintenance, releases and the MIT licence
Releases land on a roughly two-month cadence in the supplied data: v3.3.1 in February 2026, v3.3.2 in June, v3.3.3 later in June, with the last push to main in July 2026. That is a maintained project, not an abandoned one, and the patch-level versioning suggests incremental fixes rather than a rewrite in progress. The licence is MIT, which is permissive: you can read the source, fork it, and ship a modified build, subject to keeping the copyright notice and licence text. MIT gives no patent grant and no warranty, and it says nothing about the Cloudflare or Kubernetes trademarks the app interacts with. That is a description of the licence text, not legal advice; if you plan to redistribute a modified build inside a company, have someone check the notice requirements. Upgrade cost is low by construction: Homebrew handles the macOS cask, and Windows users re-download the .zip, so there is no migration step described anywhere in the README.
Who should install it, and what to check first
Install it if you run kubectl port-forward daily and are tired of restarting tunnels after every sleep cycle, and if your Mac is on macOS 15.0 or newer. Skip it if you work primarily on Linux, if your macOS is older than 15.0, or if port cleanup happens inside CI where a GUI cannot run. Also skip it if you want port configuration under version control, because nothing in the README suggests a config file exists. Before installing, verify two things. First, that brew install --cask productdevbook/tap/portkiller resolves against the tap you expect, since the cask is third-party. Second, open the v3.3.3 release notes and confirm the Kubernetes and Cloudflare features are described there with the depth you need, because the README gives each of them a single bullet and no detail on authentication, tunnel startup, or which signals the kill buttons send. Those two checks take a few minutes and tell you more than the feature list does.
Editorial conclusion
Adopt PortKiller if you already run kubectl port-forward sessions by hand and want auto-reconnect plus a menu bar list instead of a terminal window per tunnel, and if your machines are macOS 15.0+ or Windows 10+. Skip it on older macOS, on Linux, or if you need scripted port cleanup in CI, where lsof -ti:PORT | xargs kill does the job without a GUI. Before installing, confirm the Homebrew cask resolves to the productdevbook tap and check the release notes for v3.3.x to see whether the Kubernetes and Cloudflare features you need are present in that build, since the README describes them in one line each.
Community notes