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.

The manifest notes that two other feature sets should not be included in 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 may cause problems with dependencies. The installed command is named btm; ensure Cargo's binary installation directory is on your PATH.

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; compare the package version and build features with your needs before choosing an installation method.

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. A custom layout may require reading the configuration documentation and writing a file; the default layout and command-line options can also be useful without customization. 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. 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. 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-11-01 and 2026-10-31 and the 0.15.0 stable release from 2026-11-01, matching the package version 0.15.0 in Cargo.toml. Nightly tags are not the same as tagged stable releases. The last push to the repository was on 2026-11-02, so work is ongoing. 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. Those platforms may receive limited support, and the README notes that builds, tests and fixes are not assured.

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 may be available through your distribution's packages; compare the versions, features and resource use on your own systems.

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. 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. Platform-specific dependencies and runtime availability vary, so consult the manifest and build documentation before disabling features or installing libraries.

Editorial conclusion

bottom is a configurable terminal monitor for Linux, macOS and Windows. Its interface is familiar across platforms, but available metrics and features can differ by operating system, permissions and build. Try the default layout before customizing it, check the current platform-support and release documentation, and test a pinned package and your configuration before wider deployment.

Frequently asked questions

Official sources

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