# NeoHtop: a Tauri and Svelte desktop monitor for people who want htop looks with a GUI

> NeoHtop is a cross-platform system monitor built with SvelteKit, Rust and Tauri, distributed as a desktop app. It is pleasant to install and easy to read, but its process management and privilege model are narrower than the terminal tools it borrows its name from.

**Abdenasser/neohtop** — 💪🏻 Blazing-fast system monitoring for your desktop (built with Rust, Tauri & Svelte)

- Repository: https://github.com/Abdenasser/neohtop
- Website: https://abdenasser.github.io/neohtop/
- Stars: 9,393 · Forks: 310
- Language: Svelte
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/abdenasser-neohtop

## The gap NeoHtop fills between top and a desktop task manager

Terminal monitors are fast and ubiquitous, but they are built for a keyboard and a terminal emulator. Desktop task managers are graphical, but they tend to hide the details an engineer wants: full command lines, PIDs, per-process CPU and memory, and a sortable table. NeoHtop sits in that middle space. The README describes it as a modern, cross-platform system monitor built on Svelte, Rust and Tauri, and the feature list is exactly what you would expect from that positioning: real-time process monitoring, CPU and memory tracking, dark and light themes, search and filtering, pinning, sorting by any column, killing processes, and auto-refresh.

The audience is a developer or sysadmin on a laptop or workstation who wants a window they can leave open next to an editor. It is not aimed at fleet monitoring, log aggregation, or remote hosts. The homepage at abdenasser.github.io/neohtop and the releases page are the two places the project points users toward, and the README links to a personal blog post for the back story rather than documenting a design rationale in the repository.

One thing worth noticing: the project is a desktop shell around an OS process table, not an agent. There is no server component, no remote protocol, and no configuration file described in the README. That keeps the mental model small, and it also means anything you want to correlate across machines is out of scope.

## How the Svelte frontend talks to the Rust backend

The repository layout makes the split explicit. src/ holds the SvelteKit application, src-tauri/ holds the Rust side, and package.json lists @tauri-apps/api, @tauri-apps/plugin-os and @tauri-apps/plugin-shell as dependencies alongside Svelte 5 and SvelteKit 2. Tauri's model is that the webview renders the interface and Rust commands answer requests over the IPC bridge, so the process list you see is data the Rust side collected and handed to Svelte for display.

The plugin list is informative about what the app is allowed to do. plugin-os is used for platform detection, which is consistent with the cross-platform claim and with the macOS-specific sudo path in the README. plugin-shell is the more interesting one: killing a process is a shell-level action, and exposing that from a webview is why Tauri applications are usually distributed as signed native binaries rather than as a web page. The README notes that the macOS release is notarized by Apple, which is the practical consequence of that architecture.

Build tooling is conventional for the stack. The frontend uses Vite 6 with @sveltejs/adapter-static, so the Svelte side compiles to static assets that Tauri bundles. Formatting is split by language: Prettier for src/, cargo fmt for src-tauri/. A husky pre-commit hook runs lint-staged over both. That is a tidy setup, and it also tells you the project expects contributors to touch both halves of the codebase rather than treating the UI as a separate concern.

## Installing NeoHtop on macOS, Linux and Windows

The README offers two routes. The manual route is to download the latest release from the GitHub releases page; the package-manager route goes through community-maintained packages. The README is direct about the distinction: it says the community packages are not officially released, reviewed or endorsed, and that official builds come only from GitHub Releases. Read that sentence before you pick a channel.

On macOS, the cask is the shortest path. The README gives this command:

```bash
brew install --cask neohtop
```

After it completes, NeoHtop appears in your Applications folder like any other cask-installed app. Because the README states the release is notarized by Apple, you should not need to bypass Gatekeeper for the official build; if you installed through a third-party package, that guarantee does not transfer.

On Arch Linux the README points at the AUR and an AUR helper:

```bash
yay -S neohtop
```

The alternative helper command is paru -S neohtop. Fedora users are told to install the Terra repository first, then run dnf install neohtop. Windows users add the Scoop extras bucket and install from it:

```bash
scoop bucket add extras
scoop install extras/neohtop
```

Solus users get eopkg install neohtop. Once the app is open, the first real use is to sort the process table by CPU or memory and then narrow it with the search box. Search accepts a process name, a command fragment or a PID, and commas act as OR. The README's examples are worth copying: arm, x86 returns processes matching either term, d$ lists daemons, and ^(\w+\.)+\w+$ matches reverse domain name notation such as com.docker.vmnetd. Regular expressions are supported, so a bad pattern is a real possibility and the README does not describe what happens when one fails to compile.

## Seeing root-owned processes and where the privilege model stops

A process monitor that runs as your user cannot see everything. The README addresses this with a sudo launch path rather than a privileged helper. On macOS it gives the binary path directly:

```bash
sudo /Applications/NeoHtop.app/Contents/MacOS/NeoHtop
```

On Linux it recommends pkexec with the path to the binary, for example pkexec /path/to/neohtop. Launching the whole application as root is a blunt instrument. It works, and it avoids the complexity of a setuid helper, but it means the entire webview and its IPC surface run with elevated privileges. For a personal workstation that is a trade-off many people accept. On a shared or hardened machine it is the kind of decision a security reviewer will want to revisit.

There is a second, quieter limitation. The README does not document rollback, undo, or any confirmation step around killing a process, and it does not describe safeguards against killing a process you did not mean to select. The feature list simply says process management (kill processes). Treat that as a sharp tool: the pin feature exists, and pinning the processes you care about before you start filtering is a reasonable habit, but it is a habit, not a documented guardrail.

Finally, the sudo instructions are platform-specific and the README gives no Windows equivalent. If your workflow depends on seeing system-owned processes on Windows, the documentation is silent on how to get there.

## The CLI sibling, and why it is not just NeoHtop in a terminal

The README's most prominent block is not about the desktop app at all. It announces NeoHtop CLI, a separate project at github.com/Abdenasser/neohtop-cli, built with Go and the Charm ecosystem and published on npm. The install line is npm install -g neohtop-cli. The advertised feature set overlaps heavily: real-time CPU sparklines, memory bars, a process tree view, search, filters and themes, on macOS, Linux and Windows.

That overlap is the interesting part. If you already live in a terminal, the CLI is the more natural fit, and it is a different codebase in a different language with a different distribution channel. The desktop app's advantage is not the data; it is the presentation. A GUI window with a sortable table, pinned rows and a mouse is genuinely easier to scan while you are doing something else, and it does not require a terminal multiplexer or a font with good box-drawing glyphs.

The CLI's advantage is reach. An npm global install works over SSH on a remote box in a way a Tauri desktop application does not. The two projects share a name and a purpose but not an implementation, so bug reports and feature requests do not travel between them. Pick based on where you need to look at processes, not on which one sounds newer.

## NeoHtop compared with htop, btop and Glances

The obvious comparison is htop, and the name invites it. htop runs in a terminal, starts instantly, and is present in the package repositories of essentially every Linux distribution. It is the tool you reach for on a server you have just SSHed into. NeoHtop cannot do that job: it needs a graphical session, it ships as a native bundle, and its install story is a cask, a Scoop bucket or an AUR package rather than a single apt or dnf line. If your target is a headless machine, htop is the right answer and NeoHtop is the wrong tool.

btop is the closer visual analogue. It is a terminal application that produces a dense, colorful, mouse-aware interface, and the search data around this project shows people typing btop and even btop transparent background, which suggests a shared aesthetic expectation. The difference is delivery: btop renders in your terminal, so it inherits your terminal's font, transparency and keybindings. NeoHtop renders in a webview, so it controls its own appearance through CSS variables and offers dark and light themes, but it cannot be piped, scripted or run inside tmux.

Glances takes a third approach. It is a Python-based monitoring tool that can run in a terminal and also expose a web or API surface, which makes it useful for collecting metrics rather than only watching them. NeoHtop has no equivalent export or API in the documentation. If you need historical data or a remote endpoint, Glances or a dedicated metrics stack is the better direction. If you want a window on your own desktop that looks good and updates in real time, NeoHtop is aimed squarely at you.

## Maintenance, licensing and what the repository tells you about cost

NeoHtop is MIT licensed, and the LICENSE file sits at the repository root. MIT is permissive: you can use, modify and redistribute the code, including in commercial settings, provided the copyright notice and permission notice are preserved. That is the extent of what can be said here; specific obligations depend on how you redistribute, and that is a question for a lawyer rather than a README.

The maintenance picture is mixed and worth stating plainly. The repository is not archived, and the last push was on 2026-03-30. The most recent release listed is v1.2.0 from 2025-06-02, with v1.1.3 shortly before it and v1.1.2 back in 2024-12-08. So there is activity on the default branch after the last tagged release, and the release cadence is uneven. If you depend on a packaged build, the version you get may lag the branch.

Upgrade cost is low for the package-manager channels: brew, scoop, dnf and the AUR helpers all have their own update commands, and the README does not describe a migration step between versions. The bigger cost is the community packaging layer. Because those packages are third-party, their update frequency is outside the project's control, and a stale package is a realistic outcome. Building from source is the fallback, and the README does document it: npm install, then npm run tauri dev for development or npm run tauri build for a production bundle, with Node.js v16 or later, a recent stable Rust toolchain, and Xcode Command Line Tools on macOS.

## Conclusion

Adopt NeoHtop if you want a readable, themeable process list on a desktop machine and you are comfortable with a GUI that shows what the OS reports rather than a deep diagnostic suite. Do not adopt it as a drop-in replacement for htop on a headless server, and do not expect the packaged builds to be maintained by the project itself. Before installing, check the releases page for your platform, confirm whether the package you are about to use is the official GitHub release or a community-maintained one, and try the sudo launch path if you need to see processes you do not own.

## FAQ

### What is NeoHtop used for?

It is a desktop system monitor: it shows running processes with CPU and memory usage in real time, lets you search, filter, sort and pin rows, and can kill processes. The README describes it as a modern, cross-platform system monitor built on Svelte, Rust and Tauri.

### How do I install NeoHtop on macOS?

The README gives the Homebrew cask command brew install --cask neohtop, or you can download the latest release from the GitHub releases page. The README states the macOS release is notarized by Apple.

### Why does NeoHtop need sudo?

Some processes require elevated privileges to be monitored, so the README documents launching the app with sudo on macOS or pkexec on Linux to see them. The documentation does not describe a privileged helper, so the whole application runs elevated in that mode.

### Does NeoHtop work on Linux servers over SSH?

No. NeoHtop is a Tauri desktop application that needs a graphical session, and the README's Linux instructions cover desktop packaging through the AUR, Terra for Fedora and eopkg on Solus. For a headless machine the separate NeoHtop CLI, installed with npm install -g neohtop-cli, is the project's terminal-oriented option.

## Sources

- [Abdenasser/neohtop on GitHub](https://github.com/Abdenasser/neohtop)
- [License: MIT](https://github.com/Abdenasser/neohtop/blob/main/LICENSE)
- [Project website](https://abdenasser.github.io/neohtop/)
- [README](https://github.com/Abdenasser/neohtop/blob/main/README.md)
- [Releases](https://github.com/Abdenasser/neohtop/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/abdenasser-neohtop