Four years without a release

The last release of bcicen/ctop is version 0.7.7 and dates from March 22, 2022. The last commit in the repository is from August 1, 2022. Since then: nothing.

That's not a criticism. Anyone who carries an open source project alone for years is allowed to stop at some point. It just doesn't change the fact that the software keeps running, on my servers and in my development environments, every day.

I used ctop for years without ever looking at the code. At some point, govulncheck reported the first vulnerability in a dependency, and it was clear that no one would fix it.

What I found when taking over

The code was well written, but at 2022's level. io/ioutil instead of os, a logging package that hasn't been maintained in years, a UUID library from a deleted account.

More serious were three findings from the first round. container.Exec() passed user input via sh -c further, which allowed a shell injection. The configuration file was created with world-readable permissions. And the debug server bound to 0.0.0.0, so it was reachable on the entire network as soon as someone CTOP_DEBUG=1 set.

A fourth was added later in the runC connector: a channel that was never initialized. Sends and receives on it block silently and forever in Go. The code only ran because this path was rarely hit in practice.

What I stand behind

I don't promise new features on a monthly cadence. What I commit to is narrower and therefore more robust.

Dependencies stay current. Dependabot checks Go modules, GitHub Actions, and the Docker base image weekly, and govulncheck runs in the build pipeline and fails if a known vulnerability slips through.

Security issues get patched, not documented and left alone. When runc reported three container escapes in fall 2025, there was a release for it, and a second one in the November follow-up.

Builds are available for five platforms. Each release ships binaries for Linux, macOS, and Windows along with SHA256 sums, a multi-arch image on GHCR, and an updated Homebrew formula. It's triggered by a Git tag, and GitHub Actions handles everything else.

What the fork won't be

No rewrite. No feature race with lazydocker or k9s. ctop remains a tool that does one thing.

A bigger change is still coming. The two libraries that the terminal interface is built on, gizak/termui and nsf/termbox-go, are themselves no longer maintained. The plan for the migration to the Charm stack is in the repository as a six-phase document. I haven't started on it yet.

What the tool can do today and how to install it is on the project overview. If you use ctop and something is missing or stuck: Issues are open, pull requests too.