isd: a systemd unit browser that treats sudo as something the tool should handle for you

The feature list is a list of small frictions removed

The tagline is that isd is a better way to work with systemd units, and the feature block is short enough to quote as a description of what the tool actually does.

You can quickly switch between `system` and `user` units, which matters more than it sounds because the two scopes are separate namespaces and most tools make you remember which one you are in. Units are found with fuzzy search, previews refresh automatically rather than on a keypress, and output can be opened in a pager or an editor. Sudo is prefixed automatically when required, so you are not retyping `sudo systemctl` on every privileged action.

The rest is interface work: the layout rescales with the terminal window, there is an extensive command palette, keybindings are fully configurable, common inputs can be cached, themes are supported, and configuration lives in a YAML file with auto-complete.

The caching entry is the one that tells you something about the intended audience. Remembering inputs is not something a tool does for a user who runs four commands a day.

Installation through three channels

The README says installation is available via `uv`, `nix`, and as an AppImage, and points at the official installation documentation for details rather than duplicating them. Documentation lives at kainctl.github.io/isd and there is a demo recording hosted with the repository, plus a link to a higher quality version on the documentation site.

The repository reflects all three channels. There is a `flake.nix` alongside `flake.lock` for the Nix path, a `build.sh` at the root, a `share/` directory holding an application icon at 512x512, and a `pyproject.toml` that declares the package name as `isd-tui`.

The packaging metadata is also where the licensing question is answered, and it does not match what the repository reports. GitHub's license field for this project shows no license, while `pyproject.toml` states:

license = "GPL-3.0-or-later"
license-files = ["LICENSE"]

A `LICENSE` file is present in the tree, and the classifiers include the GNU General Public License v3 or later entry. The metadata is the more specific claim, so that is the one to rely on.

Six small Python dependencies

The dependency list is short enough to be worth reading in full, because for a TUI that shells out to systemctl every choice is visible.

dependencies = [
    "xdg-base-dirs>=6.0.0",
    "pfzy>=0.3.4",
    "textual>=3.0.0",
    "pydantic-settings[yaml]>=2.7.0",
    "pydantic>=2.10.4",
    "types-pyyaml>=6.0.12.20241221",
]

`textual` at version 3 or later is the TUI framework and does the heavy lifting. `pfzy` is the fuzzy matcher behind unit search. `xdg-base-dirs` resolves the configuration location in the platform-appropriate way. `pydantic` and `pydantic-settings` with the YAML extra are how the config file gets a schema and validation rather than ad-hoc parsing.

The Python floor is 3.11 or later. The declared version is 0.6.3, and the comment above the version field explains why it is hardcoded rather than derived: versioningit was tried and abandoned because it caused too many packaging issues across distributions.

The project also carries `macros.py`, `render_theme.py`, a `demo.tape` for the VHS terminal recorder, and `record_demo.sh`. The README acknowledges mkdocs-material for the documentation and asciinema and vhs for the recordings, which is a good sign about how much attention the non-code parts get.

A roadmap with two items already done

The roadmap section is explicit that the list is unordered ideas, and it uses checkboxes so you can see what has landed.

Two are done: adding an icon for the project and application menu, and support for older systemd versions. That second one matters more than it looks, because the tool's whole interface depends on parsing systemctl output and on the behaviours of the version in front of it.

The open items are more revealing about where the tool is. Viewing the security rating of units is unimplemented. Improving highlighting of systemd units with a tree-sitter grammar is listed, which tells you the current highlighting is regex-based and therefore approximate. Writing a custom, more secure `$EDITOR` integration, described in the same line as a more secure `systemctl edit`, is on the list, and that is a genuine security item rather than a polish item. Allowing customisation of preview windows, improving `journal_pager` integration, adding custom sort options, making fuzzy search faster, and improving the default themes complete the list.

The acknowledgement section credits systemd itself, NixOS for the interest in service managers, `sysz` as the starting point for a systemctl TUI, textual for making TUIs in Python straightforward, and posting for showing the author how to use textual. The sysz credit is the useful one for anyone comparing tools: isd is explicitly a more ambitious successor to an existing systemctl TUI.

Release notes that are all about colour

The two most recent releases on record are both about appearance, which tells you what the author has been working on.

v0.6.2, published 2026-03-08, is described as a small bug fix release that makes the experimental `terminal-derived-theme` option selectable in the theme menu. Previously it only worked when defined directly in settings. The same release lets you declare whether that theme is `light` or `dark`, defaults to `dark`, uses the setting to adjust contrast against the background, and adds a guess at whether `TRUECOLOR` is supported by inspecting the `TERM` environment variable. Dependencies were also updated so more upstream textual themes became available.

v0.6.1, from 2025-10-06, fixed colour clashes across themes and made the ansi colours resolve to theme colours, so the green in search results and the preview window adapts to the selected theme. It also introduced the experimental terminal-derived theme.

That is a narrow band of work for a project with 2,146 stars, and it suggests the interface has been iterated on after the feature set settled. The repository is not archived, has 23 forks and 8 open issues, and its last push was recorded on 2026-05-16.

Where the README stops and the documentation starts

The README for this project is mostly an index. It links to the documentation site twice, once for installation details and once for the higher quality demo, and it keeps the tagline, feature list and roadmap in marked blocks, which is the pattern used by tooling that generates documentation sections from the README.

Everything a user actually needs is on that documentation site: installation commands for uv, Nix and AppImage, the keybinding reference, the configuration file format with its YAML options, and the theme documentation that v0.6.2's release notes point to for the `light` and `dark` question.

What the README does give you is a fair summary and an unusually honest backlog. If the deciding factor is whether the tool handles system and user units, search, previews and sudo for you, the feature list answers that in ten lines. If the deciding factor is whether the configuration file will fit your existing setup, the documentation site is where that question gets answered, and the pydantic-based schema is a good sign that the config is validated rather than guessed at.

Editorial conclusion

isd is a pleasant front end for the part of systemd work that is really browsing: finding a unit, reading its status and recent output, opening a pager. It does not replace `systemctl`, and the README does not pretend otherwise, but the auto sudo prefixing and the auto-refreshing preview remove the two frictions that make a TUI annoying in practice. Two practical notes for anyone evaluating it. The GitHub license field reports no license while `pyproject.toml` declares GPL-3.0-or-later with the LICENSE file included, so treat the packaging metadata as authoritative. And the roadmap lists several unfinished items that affect daily use, including a more secure `systemctl edit` integration and a tree-sitter grammar for better unit highlighting.

Frequently asked questions

Official sources

1. Issues
2. kainctl/isd on GitHub
3. Project website
4. README
5. Releases