jetson-stats: A terminal monitor and Python API for NVIDIA Jetson boards

What jetson-stats solves and who it is for

The package is designed to work without superuser for most operations. The README states it does not need superuser, although the pip installation commands all use sudo. That distinction matters: you can run jtop as a normal user, but installing the package typically requires root unless you use the specific script for running without sudo. The README includes a script, install_jtop_torun_without_sudo.sh, for Jetson Developer Kits. That script is the only path to a no-sudo install, and it is only mentioned for the AGX Thor Dev Kit explicitly. For other boards, the README says the method works on all Developer Kits, but it does not show the exact behavior.

How jtop and the Python library expose board data

One trade-off is that the socket introduces a moving part. If the background service is not running, jetson.ok() will likely return False, and the loop exits. The README does not document how to start the service manually or what happens if the socket is missing. For a Docker container, you must install jetson-stats on the host and in the container, and then mount the socket. That is two installations and a mount, which is more setup than a plain pip install. The README does not explain why the host install is required; it just says to do it.

Installation: four paths, each with a caveat

The README gives four installation options. Option 1 is sudo pip3 install -U jetson-stats, which requires superuser. Option 2 is the same but from GitHub. Option 3 targets Ubuntu 24.04 and adds --break-system-packages to the pip command, because newer Ubuntu versions block pip from installing into system Python. Option 4 is a curl script that installs jtop to run without sudo. That script is the only way to avoid sudo for the install, and it is the only option that mentions a specific board, the AGX Thor Dev Kit. The upgrade path is a separate script, upgrade-jtop.sh, also fetched via curl. None of these options mention a virtual environment, but the README says you can use jtop with a virtualenv, pointing to an advanced usage page. The pip install from PyPI is the most direct route, but the --break-system-packages flag on Ubuntu 24.04 is a sign that the package is not fully aligned with PEP 668. That flag overrides a safety mechanism, so you should be aware of what you are bypassing.

Docker integration: a socket mount, not a device mount

The Docker workflow is unusual. You do not pass /dev/nvhost or other device nodes. Instead, you pass /run/jtop.sock. The command in the README is docker run --rm -it -v /run/jtop.sock:/run/jtop.sock rbonghi/jetson_stats:latest. This assumes the host has jetson-stats installed and running, because the socket is created by the host service. The container then reads telemetry through that socket. This is a clean separation: the container does not need privileged access to the host kernel. The trade-off is that the container cannot control hardware directly, only what the socket exposes. The README does not say whether the socket supports control operations like setting fan speed from inside a container. If you need to control the fan from a container, you may need to run the control on the host instead. The Docker image is published on Docker Hub under rbonghi/jetson_stats, but the README does not give a tag list or a size estimate.

Limitations and cases where it is the wrong tool

The README claims the package works with all NVIDIA Jetpack versions, but it does not list which versions. That is a broad claim, and for a project that reads kernel interfaces, you should verify it on your specific L4T release. The package is also AGPL-3.0 licensed. That is a strong copyleft license. If you import jtop in a Python script and distribute that script, the AGPL terms apply to your code. For internal tools that never leave your organization, this is usually not a problem. For a commercial product that you ship, it can be. The README does not discuss licensing implications, but the LICENSE file is linked. Another limitation is that the package is Python-only. If your monitoring stack is Go or Rust, you would need to run a Python sidecar. The socket design means you can do that, but it is an extra process. The README also mentions Discord for community support, which is informal; there is no mention of a formal issue tracker or SLA.

Alternatives: what else you could use

The obvious alternative is to read the sysfs and /proc interfaces directly. NVIDIA provides /sys/devices/system/cpu/cpu*/cpufreq and /proc/driver/nvidia/tegra_soctherm for temperatures, but you have to write your own parser for each L4T version. That gives you full control and no dependency, but it is exactly the work jetson-stats saves you. Another alternative is tegrastats, a command-line tool that comes with Jetpack. tegrastats prints a single line of stats at a fixed interval. It is simpler, but it does not offer control of fan speed or NVP model, and it is not a Python library. jetson-stats is more capable than tegrastats for scripting and control. If you need remote monitoring over HTTP, you would pair jetson-stats with a web server or use a different tool like Prometheus node_exporter with a custom collector. The README does not mention any of these alternatives, so this comparison is based on general knowledge of the Jetson ecosystem, not on the project's documentation.

Maintenance and upgrade cost

The project has recent releases: 7.2.1 on 2026-08-09, 7.2.0 on 2026-07-14, and 7.1.5 on 2026-03-24. That is a steady cadence of roughly one release per month. The last push date matches the latest release, so the project is actively maintained. The upgrade script, upgrade-jtop.sh, suggests that upgrading is a known workflow. The README does not describe what changes between versions, but the release numbers imply semver-ish increments. The maintenance cost for you is mostly keeping the host and container versions in sync. If you use Docker, you need to update the host package and the container image together, because the socket protocol may change between versions. The README does not state a compatibility policy for the socket protocol. The AGPL license also means that if you modify the package, you must share your changes if you distribute the result. That is a legal cost, not a technical one, but it is worth planning for.

Editorial conclusion

Adopt jetson-stats if you run a Jetson Developer Kit and need a quick, scriptable way to read CPU, GPU, memory, engine, and fan stats without writing your own sysfs parsers. Do not adopt it if your project must stay under a permissive license, because AGPL-3.0 applies to the library and to any code that imports it. Before committing, verify that the board you target is listed in the README (Thor, Orin, Xavier, Nano, TX series) and that the version of Jetpack you use is supported, since the README claims it works with all Jetpack versions but does not enumerate them. Also confirm that the socket-based Docker mount, /run/jtop.sock, fits your container security model, because that socket exposes host telemetry to the container.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes