bottom (btm): a cross-platform terminal system monitor in Rust

What bottom solves, and who ends up using it

Every operating system ships a process viewer, and none of them look alike. A developer who moves between a Linux server, a Mac laptop and a Windows workstation ends up memorising three different key bindings and reading three different layouts. bottom, invoked as btm, is one answer to that: a single terminal application that graphs CPU, memory, network, temperature and disk I/O over time, and lists processes, on all three platforms. The README describes it as inspired by gtop, gotop and htop, which places it in the TUI monitor family rather than the single-shot ps family.

The audience is narrower than "anyone who monitors a machine". You need a terminal you are happy to live in, and you need to care about history rather than a single reading. The graphing widgets keep a time window that can be zoomed in and out, so the tool answers questions like "did memory climb while that job ran" rather than "what is memory right now". If your problem is a long-running service on a headless box, and you want to see the shape of the last few minutes without wiring up Prometheus, this is the gap bottom occupies.

How the widgets are wired together

bottom is a Rust binary built with crossterm for terminal handling and clap for argument parsing, according to Cargo.toml. The binary target is named btm and lives at src/bin/main.rs, while the package is named bottom on crates.io. That split matters when you install it: the crate you fetch and the command you type are not the same string.

The feature flags in Cargo.toml describe the optional subsystems rather than a plugin architecture. battery pulls in starship-battery, nvidia pulls in nvml-wrapper and implies gpu, and zfs is its own flag. The deploy feature enables battery, nvidia and zfs together, and it is in the default set, so a plain build carries all three. A minimal build without them is possible by disabling default features, which is the practical lever if you are cross-compiling for a platform where those backends do not exist.

Two other feature sets are deliberately excluded from release builds. logging brings in fern and log, and generate_schema brings in schemars and strum. The schema directory at the repository root is where the config schema lives, which is how editors can validate a config file. The layout is a normal Rust project: src for the implementation, tests for the test suite, sample_configs for example configuration, docs for the documentation site content, and desktop and wix for packaging on desktop platforms and the Windows MSI respectively.

Installing bottom from crates.io and running it once

The README leads its installation section with Cargo, and warns that the stable Rust toolchain may need updating first. The exact commands given are:

rustup update stable
cargo install bottom --locked

The --locked flag tells Cargo to use the versions pinned in Cargo.lock. The README notes it may be omitted, with the caveat that this is not recommended. After the build finishes, the binary is on your PATH as btm, not bottom.

Running it with no arguments opens the full multi-widget view. The README shows a demo recorded with the Gruvbox theme, invoked as --theme gruvbox, which is a built-in colour theme. If you want the htop-style single list instead of the widget grid, the documentation calls that basic mode.

btm --theme gruvbox

You should see the graph widgets and the process table in the themed colours. From there the documented interactions include searching within the process widget, expanding a widget to fill the screen, and sending kill signals to a selected process. If the screen looks wrong, the README's troubleshooting section is the first place to look rather than the issue tracker.

Cargo is one of many documented routes. The README also lists Alpine, Arch, Debian and Ubuntu, Fedora and its derivatives, Gentoo, Nix, openSUSE, Snap, Solus and Void on Linux; Homebrew and MacPorts on macOS; and Chocolatey, Scoop, winget, an MSI installer, Conda, gah, ghr and mise, plus pre-built binaries with an auto-completion note. Pick the one your platform already uses; there is no reason to compile from source if a package exists.

Configuration is the part that decides whether you keep it

The README lists what is configurable: custom and built-in colour themes, widget behaviour, widget layout, and filtering out entries in some widgets. It also says this can be driven either by command-line options or by a config file. That is the honest summary, and it is also where the documentation does the most work, because the command-line options page and the configuration pages are separate documents.

The consequence is that bottom is not a tool you evaluate in thirty seconds. A default install shows a layout someone else chose. Getting a layout that matches how you think about your machines means reading the configuration documentation and writing a file. The sample_configs directory in the repository exists for exactly this, and the schema directory means an editor with schema support can validate the file as you type.

There is a real cost here that the README does not dwell on. Command-line options and a config file are two sources of truth for the same settings, and when they disagree you need to know which wins. The documentation covers both surfaces; it does not present them as a single mental model. If you only ever pass flags, you avoid the question entirely, which is a legitimate way to use the tool.

Platform support is tiered, and the tiers are not decorative

The README splits support into official and unofficial, and the distinction has teeth. Official means macOS on x86_64 and aarch64, Linux on x86_64, i686 and aarch64, and Windows on x86_64 and i686. Those platforms are described as tested to work for the most part, with issues fixed if possible.

Unofficial covers FreeBSD on x86_64, Linux on armv6, armv7, powerpc64le, riscv64gc and loongarch64, Android on arm64, Windows on arm64, and NetBSD on x86_64. The README is explicit about what that means: these platforms might not be built or tested in CI, might not be checked by maintainers before a stable release, and may only receive limited support, with missing features or bugs that may not be fixed. It also notes that some of them may eventually become official, naming FreeBSD as an example.

If you are on an ARM server or an Apple Silicon Mac, read that list before you plan anything. Apple Silicon is official; Windows on arm64 is not. That asymmetry is easy to miss and expensive to discover after you have standardised on the tool.

Where bottom is the wrong choice

bottom is an interactive TUI. It is not a metrics pipeline. The README does not describe exporting samples to a file, a socket or a remote endpoint, so if you need historical data, alerting, or a dashboard that survives the terminal closing, this is not the tool. You would be looking at a time-series system instead, and bottom would sit alongside it as the thing you open when you want to look at one machine by hand.

The release history is the second constraint. The three most recent releases listed are nightly builds dated 2026-09-18, 2026-09-17 and 2026-09-16, while the package version in Cargo.toml is 0.14.9. Nightly tags are not the same as tagged stable releases, and the README does not document a rollback procedure if a nightly misbehaves. The last push to the repository was on 2026-09-18, so work is ongoing, but ongoing work is not the same as a stable release cadence. If your change-control process requires pinned, versioned artefacts with a documented downgrade path, verify what your package manager actually ships before committing.

Third, the unofficial platform list is a real boundary rather than a formality. On those architectures you are on your own in a way the README states plainly.

bottom against htop, and why the difference is not cosmetic

htop is the obvious comparison, and bottom's own README names it as an inspiration. The difference in approach is what each one puts on screen. htop is a process table with a small set of meters above it; the primary object is the process list, and system state is context. bottom inverts that. The graph widgets, CPU over time at average and per-core level, memory and swap, network I/O, temperature and disk I/O, are first-class, and the process widget is one panel among several. You can expand any widget to fill the screen, which is the mechanism that lets you switch between the two modes of thinking without leaving the application.

The second difference is portability of behaviour. htop is a Unix tool; the README of bottom states support for Linux, macOS and Windows, which is a different claim. If your fleet mixes Windows workstations with Linux servers and you want one monitor with one configuration format, that is the case bottom is built for and htop is not. If your fleet is Linux only, htop is smaller, older, and available in essentially every distribution's base repositories, and bottom's extra widgets may be more than you need.

A third option worth naming is gotop, also cited as an inspiration, which occupies similar ground. The honest distinction available from the README is breadth of platform support and the configuration surface, not raw capability.

Licence and the ongoing cost of keeping it current

bottom is MIT licensed, per Cargo.toml and the LICENSE file at the repository root. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are retained. If you vendor the source into a product, keep the notice. That is the general shape of the obligation, not legal advice for your situation.

The upgrade cost is dominated by the config file. Because layout, widget behaviour and themes are user-configurable, a config written against one version is the thing most likely to need attention after an upgrade, and the schema directory exists so your editor can flag drift. The README does not promise config stability across versions, and it does not document a migration tool. Practically, that means testing a new version against your real config on one machine before pushing it to the rest.

On the build side, Cargo.toml sets rust-version to 1.95.0 and edition to 2024, with a comment noting that this is not an official MSRV. If you compile from source in CI, treat 1.95.0 as a floor that the maintainer has tested, not a guarantee. The default feature set includes battery, nvidia and zfs, so a build on a machine without those libraries needs the flags turned off deliberately.

Editorial conclusion

Adopt bottom if you want one monitor binary that behaves the same on Linux, macOS and Windows, and you are willing to write a config file to get the layout you want. Skip it if you need a stable release cadence or vendor support: the recent releases in the repository are nightly builds, and the README does not describe a rollback path. Before rolling it out, run btm --help on your target platform and check the official support page for your architecture, because the README lists several architectures as unofficial.

Frequently asked questions

Official sources

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