somo: a netstat replacement that reads like a table, not a wall of text

The problem somo solves, and who actually needs it

netstat output is a fixed-width text dump. You get a list of sockets, and then you pipe it through grep and awk to answer a question as simple as "what is listening on 5433". somo's pitch is stated in its own description: a human-friendly alternative to netstat for socket and port monitoring on Linux and macOS. The README compresses the workflow shift into one line, framing the move from `netstat -tulpn` to `somo -l`.

The target user is a developer or sysadmin on a Linux or macOS machine who is already comfortable in a terminal and wants to skip the parsing step. It is not aimed at people who need a monitoring agent, a metrics pipeline, or a daemon that records socket state over time. somo is an inspection tool you run when you want an answer now, and the feature set reflects that: filtering, sorting, a compact view, and an interactive kill option. If your question is "what has been happening on this port for the last six hours", somo does not store history and the README does not claim it does.

How somo collects socket data on Linux and macOS

The Cargo.toml is the clearest evidence of the architecture. Linux and macOS take different paths. On Linux, somo depends on `procfs` 0.18.0 under the `cfg(target_os = "linux")` target. On macOS, the dependencies are `netstat2` 0.11.2 and `libproc` 0.14.10 under `cfg(target_os = "macos")`. There is no single cross-platform socket library doing the work; the platform-specific backends are selected at compile time.

That design has a consequence worth naming. The two backends are separate code paths, and the README does not document behavioural differences between them. A filter or sort that behaves one way on Linux is not guaranteed to behave identically on macOS, because the underlying data source is not the same. The repository layout supports this reading: `src/` holds the shared logic, `nix/` holds the Nix build, and `tests/` holds the test suite, with a `tests/mock` directory excluded from the published crate via `exclude = ["/tests/mock/**"]` in Cargo.toml.

The rest of the dependency list is presentation and interaction. `clap` 4.6.1 with the derive feature parses arguments, `clap_complete` 4.6.5 generates shell completions, `termimad` 0.35.1 renders the table, `inquire` 0.9.4 drives the interactive kill selection, `handlebars` 6.4.1 backs the custom `--format` strings, and `serde` plus `serde_json` produce `--json` output. `nix` 0.31.3 with the process, signal and user features is what makes process killing and user filtering possible.

Installing somo and running your first real query

The README lists cargo as the primary install path. The crate is published on crates.io, so this pulls the released version:

cargo install somo

The README notes that most of the time you will want to run somo with `sudo` to see all processes and ports, and gives a symlink recipe so the binary can be reached with root privileges:

sudo ln -s ~/.cargo/bin/somo /usr/local/bin/somo
sudo somo

There are also packaged routes. Debian users are pointed at the releases page for a `.deb` file. Arch users get `yay -S somo`. Nix users can build from flakes, and Homebrew ships a `somo` formula for macOS and Linux:

brew install somo

Once installed, the README's minimal invocation is just `somo`, or `sudo somo`. A more useful first query is the one the README itself uses as its headline example: `somo -l` shows listening connections, which is the direct replacement for reaching for `netstat -tulpn`. From there, the filter flags compose. `somo -t -l` narrows to TCP listeners, and `somo -p 5433` narrows to a local port. To get a smaller table, add `-c`; to sort by process ID, add `--sort pid`; and to reverse that order, add `-r`.

For scripting, `--json` returns the connection data as JSON, and `--format` takes a handlebars-style template where attributes must be written in snake_case:

somo --format "PID: {{pid}}, Protocol: {{proto}}, Remote Address: {{remote_address}}"

The README is explicit that the attribute names are snake_case, so `{{remote_address}}` works and a camelCase variant would not. If you want defaults applied on every run, `somo generate-config-file` creates a config file, `somo --config-file` prints its path, and `somo --no-config` ignores it. The README's example config uses the same flags you would pass on the command line, one per line with a comment above.

Deprecated flags, the sudo requirement, and where somo is the wrong tool

Two flags in `somo --help` are marked deprecated. `--proto <PROTO>` is deprecated in favour of `--tcp` and `--udp`, and `--exclude-ipv6` is deprecated in favour of `--ipv4`. They still appear in the help output, so they are not removed, but anyone writing a script against them is writing against a flag the project has already signalled it wants to retire. The README's filter table repeats the same deprecation notes. If you have an existing wrapper script around somo, that is the first thing to check.

The sudo point is a real operational constraint rather than a footnote. Without elevated privileges, somo cannot see all processes and ports, which means the table is incomplete in exactly the situation where you most want completeness: a port is bound and you cannot tell by what. The README's symlink workaround exists because `cargo install` places the binary in `~/.cargo/bin`, which is not on root's PATH in a typical setup. Homebrew and distro packages sidestep this, but the cargo path does not.

Where somo is the wrong tool: it is not a continuous monitor, and the README describes no daemon mode, no history, and no alerting. It is also Linux and macOS only, which is stated in both the description and the README. On Windows, or on a host where you need socket data streamed into a metrics system, somo gives you a snapshot and a JSON blob, and the rest is your problem. The interactive kill feature is convenient, but it is a destructive action behind a single flag, and the README does not document a confirmation step beyond the interactive selection itself.

How somo differs from lsof and ss

The obvious comparison is `lsof -i`, which also maps sockets to processes and also usually needs elevated privileges. The difference is in the shape of the output and what you do next. `lsof` is a general-purpose open-file tool that happens to cover network sockets; its output is a long list with a column layout tuned for reading, not for filtering, and you narrow it with `-i`, `-p` and `-u` flags that predate any notion of a sortable table. somo inverts that: the table is the product, and the filters exist to feed it. The README's own framing, `netstat -tulpn` to `somo -l`, is the cleanest statement of the intent.

The closer comparison on Linux is `ss`, which is faster than netstat and already has filter syntax like `ss -tlnp`. `ss` does not offer JSON output in the same way, does not offer handlebars-style custom format strings, and does not offer an interactive kill selection. What `ss` has that somo does not is a much longer history and a stable flag set that distributions ship as part of iproute2. If you are writing a script that must run on a machine where you cannot install extra binaries, `ss` is already there and somo is not.

A third option worth naming is a purpose-built port checker or a process manager's own tooling. Those tend to answer a narrower question, such as whether one specific port is free, and they do not give you the full socket table. somo sits in the middle: broader than a single-port check, more structured than lsof, and more presentable than ss.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-21. Releases have been reasonably regular across 2026: v1.3.3 on 2026-04-30, v1.3.4 on 2026-08-17, and v1.4.0 on 2026-09-12. Cargo.toml pins the package version at 1.4.0, matching the latest release. The CHANGELOG.md at the repository root is where version-to-version changes are recorded, and it is the file to read before upgrading, particularly given the two deprecated flags.

Upgrade cost from the cargo path is low: `cargo install somo` again, and the binary is replaced. If you installed via Homebrew or a distro package, the upgrade follows that package manager instead, which means the version you get may lag the crates.io release. The README warns that the master branch and its readme may include features that are not yet released, and points to the crates.io page for the official stable version and documentation. That warning applies to the two source-based install routes as well: `cargo install --git https://github.com/theopfr/somo` and the Nix flake build are both labelled as cutting-edge development versions that may be unstable or contain incomplete features.

On licensing, somo is MIT. That is a permissive licence, and it is the same licence declared in both the repository metadata and the `license` field of Cargo.toml. What that means for your own distribution or redistribution is a question for your legal team, not something this article can settle; the practical point is that the licence is stated consistently in two places and there is no separate commercial tier mentioned anywhere in the repository.

Editorial conclusion

Adopt somo if you inspect sockets interactively and want filtering, sorting and process killing in one command, or if a script needs socket data as JSON. Do not adopt it if you need a stable machine interface that will not change between versions, or if you are not on Linux or macOS. Before relying on it, check the CHANGELOG for the flag deprecations (`--proto`, `--exclude-ipv6`) and confirm whether your config file uses any of them, since those flags still work but the README marks them deprecated in favour of `--tcp`/`--udp` and `--ipv4`/`--ipv6`.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. theopfr/somo on GitHub