procs: a Rust replacement for ps with ports, Docker names and a tree view

What procs solves that ps does not

ps gives you a stable, scriptable table. What it does not give you is the port a process is listening on, the container it belongs to, or how fast it is reading and writing. procs is built around those gaps. The README lists the additions directly: TCP/UDP port, read/write throughput, Docker container name, and more memory information. It also colours the output, detects the terminal background to pick a theme, and pages long output automatically.

The audience is the person who reaches for ps, then pipes it into grep twice, then opens another terminal to find which container owns a PID. procs collapses that into one command with a search syntax: a non-numeric keyword matches USER and Command by default, a numeric keyword matches PID exactly. The README notes that numeric is an exact match and non-numeric is a partial match by default, which is the behaviour most people expect from a process search but not from ps.

Search logic, watch mode and the tree view

Search keywords combine through four flags: --and, --or, --nand and --nor. The default operator is set in the configuration file under the [search] section, so a team can settle on one behaviour instead of typing the flag every time. Column sets for keyword matching are configurable through nonnumeric_search and numeric_search, which is how you make a keyword hit the port column or the Docker column rather than just USER and Command.

Watch mode is the second mechanism. --watch refreshes every second; --watch-interval takes a number of seconds. Inside watch mode, n moves the sort column to the next one and p moves it back, per the keyboard shortcut list in the README. That is a narrower interaction model than top's, and the README does not document a way to change the refresh interval once watch mode has started.

Paging is automatic: if output lines exceed the terminal height, a pager is used. On Linux and macOS the default is less, falling back to more if less is missing, and use_builtin switches to the built-in pager instead. On Windows the built-in pager is always used. This matters for scripting, because automatic paging is helpful interactively and unwanted in a pipe.

Installing procs and running a first search

The README lists many installation routes. On Debian-family and Fedora hosts the distribution package is the shortest path, and on macOS Homebrew and MacPorts are both listed. The examples below are copied from the README.

sudo dnf install procs

On Arch the package is in the extra repository, and on Alpine it comes from the Alpine repository after enabling the correct one.

sudo pacman -S procs

If you want a specific version or your distribution has no package, the release page carries prebuilt binaries, and cargo builds from source. Cargo.toml declares rust-version = "1.88", so an older toolchain will refuse to build.

cargo install procs

Once installed, running procs with no arguments shows every process the user can see. Adding a keyword narrows it.

procs zsh

A numeric keyword is matched against PID exactly, and multiple PIDs can be combined with a logical operator. The README's example uses --or with several PIDs.

procs --or 6000 60000 60001 16723

Expect a coloured table sorted by CPU by default, with the columns your configuration enables. If the output is longer than the terminal, it will open in less rather than scroll past.

Permissions decide how much procs can show

This is the limitation that bites first. On macOS, the README states that normal users cannot access any information on other users' processes. On Linux, normal users cannot access some information, read/write throughput being the named example, for other users' processes. Running under sudo is the documented fix, and the README shows adding a NOPASSWD entry in /etc/sudoers for the procs binary path to avoid the password prompt.

The port column has a separate constraint. The README says procfs permissions only allow identifying listening ports for processes owned by the current user, so not all ports appear unless procs runs as root. That undercuts the port feature in exactly the shared-host case where it would be most useful. A root-owned service listening on a port will not show that port to an unprivileged procs, and the README does not offer a capability-based alternative such as granting read access to /proc through a group.

Docker support has its own gate. The Docker column appears only if you have access permission to the docker daemon at unix:///var/run/docker.sock, and the README states that Docker Toolbox on macOS is not supported because it does not use a UNIX domain socket. Docker Desktop for Mac is described as supported but not tested, which is a caveat rather than a guarantee. The docker feature is also on by default in Cargo.toml, so a build with --no-default-features drops the dockworker and tokio dependencies along with the column.

Platform support and what the README does not promise

Linux is the supported platform. Windows is supported. macOS and FreeBSD are labelled experimental, and the README is explicit that the macOS version is checked only in the GitHub Actions environment, with issues from real machines invited. That is an honest statement of coverage, and it should shape expectations: a macOS user is running a target the maintainer cannot verify on hardware. FreeBSD gets the same experimental label with no further detail in the README.

The README also does not document rollback or downgrade steps, and it does not describe a machine-readable output format. Searching is keyword-based, with logical operators over those keywords, not an expression language. If you need to select processes by parent PID, elapsed time or memory threshold, you are back to parsing output or using ps. The configuration file is central to the tool, but the README's configuration section is referenced rather than reproduced in the excerpt available here, so the exact key list for the [search] and pager sections has to be read from the repository's config directory.

procs against ps, top and htop

The honest comparison is with ps, because procs keeps ps's invocation style: a command name plus keywords, output to stdout. The difference is the column set and the search. ps reads its columns from a format string and its selection from -e, -u, -p and friends; procs reads its columns from a TOML configuration file and its selection from keywords with four logical operators. If your workflow is ps aux | grep, procs zsh replaces it. If your workflow is a script that parses ps output, procs is worse, because the pager may open, the colours are terminal-dependent, and the README documents no stable machine format.

Against top and htop, procs overlaps only in watch mode. top and htop are full-screen monitors with per-process signalling and interactive control; procs --watch is a refreshing table with n and p to move the sort column. The README does not document killing or renaming processes from watch mode. So procs is not a top replacement. It is a ps replacement that happens to have a refresh loop, and the tree view and pager are the parts that make it feel like a different tool rather than a reskin.

Maintenance, licence and upgrade cost

The repository is not archived. The last push was on 2026-09-16, and the most recent release listed is v0.14.12 on 2026-06-25, following v0.14.11 on 2026-02-27 and v0.14.10 on 2025-03-28. The gap between v0.14.10 and v0.14.11 is about eleven months, so release cadence is uneven even though the branch is being pushed to. Anyone pinning a version should expect to sit on it for a while.

The licence is MIT, declared in Cargo.toml and present as a LICENSE file at the repository root. MIT is permissive: it allows reuse and redistribution with the copyright notice and permission notice retained. That is a statement about the licence text, not legal advice, and the Docker feature pulls in dockworker and tokio as dependencies under their own licences, which a distributor would need to check separately.

Upgrade cost is mostly configuration drift. The binary is self-contained, so replacing it is simple, but the configuration file lives outside the binary and the README treats it as the place where search defaults, column sets and pager behaviour are decided. A version bump that changes a configuration key will not be caught by the package manager. The Makefile shows the release process uses cargo with --locked and cross-compiles to musl targets for Linux, so the published Linux artifacts are static and do not depend on a system Rust installation.

Editorial conclusion

procs is worth adopting if you spend time on Linux or Windows hosts matching processes by port, container name or command string, and you want the pager, tree view and watch mode in one binary. It is not the right tool if you need a scriptable, POSIX-stable output format, or if you rely on macOS as a production platform: the README labels macOS and FreeBSD experimental and says the macOS version is checked only in the GitHub Actions environment. Before rolling it out, verify on your own host that the Docker column appears (it needs access to unix:///var/run/docker.sock) and that your user can read the throughput columns, which the README says require sudo for other users' processes.

Frequently asked questions

Official sources

1. dalance/procs on GitHub
2. Issues
3. License: MIT
4. README
5. Releases