# GaoSSR/Kiri Review: A Rust CLI for Local Development Ports > Kiri is a Rust command line tool that lists the services listening on your local development ports, shows memory use, framework and health status, and can kill or follow the process behind a port. It installs from npm, Homebrew or a release script and targets macOS, Linux x64 and Windows x64. **GaoSSR/Kiri** — See through the fog of local development ports. Platform Support Platform | Status | - | - | MacOS arm64/x64 | Supported | Linux x64 | Supported | Windows x64 | Supported | Linux arm64 / Windows arm64 | Planned | On MacOS, Kiri uses lsof, ps, tail, MacOS log commands, and optional Docker metadata. - Repository: https://github.com/GaoSSR/Kiri - Stars: 498 · Forks: 4 - Language: Rust - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/gaossr-kiri ## What Kiri Solves, and Who Should Care Local development turns into a port bookkeeping problem. A frontend dev server, an API, a database, a queue worker, an MCP server started by an AI coding tool: each grabs a port, and when something misbehaves you are left running `lsof` or `netstat` and reading raw output. Kiri is a Rust CLI whose binary is called `ports`. Its README describes it as a "high-performance CLI for managing local development ports" and the default `ports` command prints a focused table: port, process, PID, memory usage, project name, detected framework, uptime, and health status. The audience is narrow but real: developers who run several services at once and want one view instead of three shell commands. It is not a production monitoring tool, and nothing in the README suggests it is meant to be one. ## How the Port Table Is Built Kiri is a thin, platform-aware wrapper over operating system primitives rather than a daemon that samples continuously. On macOS the README says it uses `lsof`, `ps`, `tail` and macOS `log` commands; on Linux it uses `ss`, `ps` and `/proc`; on Windows it uses PowerShell/CIM and `Get-NetTCPConnection`. Docker metadata is optional: if Docker is unavailable or no containers are running, Kiri continues without Docker mappings. That design keeps the binary small, but it also means the quality of the output depends on what those tools report, and the README notes that on Windows process working directories are best-effort from executable paths. The health labels are the interesting part. `healthy` means the process is running with a normal parent. `orphaned` means the process is still alive and may still be listening, but the parent that started it has exited. `zombie` means the process has already exited but the OS still holds an unreaped record. Orphaned processes are the everyday case: you close a terminal, IDE task or AI coding session and the child server keeps holding port 3000. ## Installing Kiri and Running ports for the First Time Kiri ships prebuilt release artifacts for macOS, Linux x64 and Windows x64. The README recommends Homebrew on macOS; npm and the install scripts use prebuilt native binaries and do not compile Rust locally. ```bash npm install -g @gaossr/kiri@latest ``` On macOS with Homebrew, the README calls this the recommended method: ```bash brew install gaossr/tap/kiri ``` macOS and Linux also have an install script: ```bash curl -fsSL https://raw.githubusercontent.com/GaoSSR/Kiri/main/scripts/install.sh | bash ``` Windows users install through PowerShell: ```powershell irm https://raw.githubusercontent.com/GaoSSR/Kiri/main/scripts/install.ps1 | iex ``` Once installed, run the bare command. You should see a small ASCII logo and a table of local development services with their ports; the README's example line reads "Kiri is watching 5 ports, 5 ports active". From there, `ports 3000` shows details for one port, `ports --all` widens the view to every listening port, and `ports ps` lists development-related processes that do not listen on a port, such as MCP Server processes started by Codex, Claude Code or other AI coding tools. When a port is stuck, `ports kill ` terminates the process behind it. ## Following Logs: ports logs and What It Assumes `ports logs ` prints recent logs and exits; adding `-f` follows the process listening on that port, and `--lines` controls how much history is shown. ```bash ports logs -f ports logs 3000 --lines 10 ``` The README says Kiri adds ANSI colors for common development log formats including Java, Python, Go, Node.js, logfmt and JSON logs, coloring timestamps, log levels, process IDs, trace IDs, source classes, HTTP values and structured fields. The constraint is where those logs come from. For services started through a terminal, the README states that a stable file-backed log such as `.dev-logs/service.log` lets `ports logs -f` follow output from another process. In other words, the tool works best when your service writes to a predictable file; it is not a general-purpose log collector, and the README does not document a fallback for services that only write to an attached terminal. ## Where Kiri Stops Being the Right Tool Three limits stand out. Platform coverage is uneven: Linux arm64 and Windows arm64 are listed as planned, not supported, so anyone on those targets cannot use the prebuilt artifacts. Docker support is described as optional metadata, which means container-to-port mapping is only as good as the Docker state at the moment you run the command; the README does not describe how Kiri behaves when a container is running but the metadata lookup fails. And the default output is deliberately terminal-shaped: `ports` intentionally renders the ASCII logo and ANSI terminal output, which is fine interactively and awkward if you want to parse the table in a script. The README does not document a JSON or machine-readable output mode, so if you need to feed port data into another tool, Kiri is probably the wrong layer. It also has no daemon and no history: it reports the state at the moment you run it, not a timeline. ## How Kiri Differs from lsof, ss and port-whisperer The direct comparison is with the tools Kiri itself shells out to. `lsof -i` and `ss -tlnp` tell you which process holds a port, and they are already installed almost everywhere. Kiri's difference is interpretation: it adds project name, detected framework, uptime, memory and the healthy/orphaned/zombie classification, and it groups the result around development services instead of every socket on the machine. That classification is the part you cannot get from `lsof` output without reading parent PIDs yourself. The README credits port-whisperer as the inspiration, specifically "the idea of making local development ports easier to see, understand, and clean up". Kiri's own additions are the Rust single-binary distribution through npm and Homebrew, the `ports ps` view for non-listening developer processes, and the log-following mode. If you only ever need to know which PID owns a port, plain `lsof` remains fewer moving parts; Kiri earns its place when you want the extra columns and the orphan detection. ## Maintenance, Releases and the Apache-2.0 Licence The repository is not archived and the last push was on 2026-07-30, which is recent enough that the project is still being worked on. The release history supports that: v0.1.22 on 2026-06-01, v0.1.23 on 2026-07-29 and v0.1.24 on 2026-07-30, so the two most recent releases landed a day apart, which suggests small, frequent cuts rather than a long release train. The version in Cargo.toml is 0.1.24, matching the latest release tag, and the dependency list is short: chrono, ctrlc, serde_json and terminal_size. For upgrade cost, that is a point in Kiri's favour. Installation is through npm, Homebrew or the install scripts, all of which pull prebuilt binaries, so upgrading is a package manager operation rather than a Rust build. Building from source requires the Rust toolchain and the README lists the maintainer workflow: cargo fmt, cargo test, cargo clippy --all-targets -- -D warnings, cargo build --release --bin ports, scripts/perf-smoke.sh and scripts/verify-release.sh v0.1.24. The licence is Apache-2.0, which permits commercial and private use and requires that you keep the licence and notice files with any redistribution; it also includes an explicit patent grant. That is a general description of the licence, not legal advice for your situation. ## Conclusion Kiri fits developers who juggle several local services and want one table with port, PID, memory, framework and health, plus a way to kill or follow the process behind a port. Skip it if you need arm64 Linux or arm64 Windows, a cross-platform GUI, or a tool that parses Docker metadata on a machine where Docker is not running. Before adopting, run ports --all and ports ps on your own machine and check whether the framework detection and health labels match what you already know about those processes. ## FAQ ### What is Kiri? Kiri is a Rust CLI for managing local development ports, distributed as a binary named ports. Its README says it shows which local services are running, which ports they use, and lets you handle the process behind a port. ### How do I install Kiri? The README lists npm with npm install -g @gaossr/kiri@latest, Homebrew with brew install gaossr/tap/kiri (recommended on macOS), a curl install script for macOS and Linux, and a PowerShell install script for Windows. The npm and script routes use prebuilt native binaries and do not compile Rust locally. ### Which platforms does Kiri support? macOS arm64 and x64, Linux x64 and Windows x64 are listed as supported. Linux arm64 and Windows arm64 are listed as planned. ### What does the orphaned status in Kiri mean? The README defines orphaned as a process that is still alive and may still be listening on a port, but whose parent process has already exited. It is distinct from zombie, which means the process has exited but the OS still holds an unreaped record. ### How do I follow logs for a process in Kiri? Run ports logs -f to follow the process listening on a port, or ports logs 3000 --lines 10 to print the last lines and exit. The README notes that for services started through a terminal, a stable file-backed log such as .dev-logs/service.log lets the follow mode work from another process. ## Sources - [Official README](https://github.com/GaoSSR/Kiri#readme) - [Project repository](https://github.com/GaoSSR/Kiri) - [Release notes](https://github.com/GaoSSR/Kiri/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gaossr-kiri