# mum4k/termdash: a Go library for building terminal dashboards

> Termdash is a cross-platform Go library for drawing dashboards in a terminal, with a layout engine, a widget set and mouse and keyboard handling. It is a library you embed in your own program, not a ready-made dashboard you install and point at data.

**mum4k/termdash** — Terminal based dashboard.

- Repository: https://github.com/mum4k/termdash
- Stars: 3,041 · Forks: 150
- Language: Go
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/mum4k-termdash

## What termdash is, and the problem it removes

A terminal program that wants to show more than a scrolling log has to solve several problems at once: splitting the screen into panes, redrawing only what changed, handling a window resize without corrupting the display, and routing keystrokes and mouse clicks to the right element. Termdash is a Go library that provides those pieces. The README describes it as a cross-platform customizable terminal based dashboard, and says the feature set is inspired by gizak/termui, which in turn was inspired by yaronn/blessed-contrib. This project is a rewrite of that idea, and the README states the rewrite focuses on code readability, maintainability and testability.

The intended user is a Go developer who is already writing a tool that produces numbers over time and wants to render them in the terminal instead of shipping a web UI. It is not an application. There is no binary to download, no config file format, and no way to point it at a data source. You import it, define a container tree, attach widgets, and feed them values from your own code.

## How the layout, containers and widgets fit together

The repository is organised around a small number of top-level packages that map to the drawing model. The container/ directory holds the layout containers, widgetapi/ holds the interface that widgets implement, and widgets/ holds the implementations. Supporting packages sit alongside them: cell/ for the terminal cell grid, align/ for alignment, linestyle/ for border styles, keyboard/ and mouse/ for input, and terminal/ for the terminal itself. The Go module depends on github.com/gdamore/tcell/v2, github.com/nsf/termbox-go, github.com/mattn/go-runewidth and github.com/kylelemons/godebug, so the terminal abstraction is not written from scratch.

The README lists two forms of setting up the layout: a binary tree and a Grid. A binary tree splits space recursively, which suits a fixed arrangement where each pane gets a fraction of its parent. The Grid form divides the screen into rows and columns, which suits dashboards where widgets sit in a table. Both are described as customizable in terms of widget placement, borders, margins, padding and colors, and the README states that layout can change dynamically at runtime.

Rendering is described as both periodic and event driven, so a widget can be refreshed on a timer or in response to input. Containers and widgets can take focus, and the README lists processing of keyboard and mouse events as a feature. Text elements use UTF-8 throughout. The widget set as documented includes Button, TextInput, Gauge, Pie, Donut, Text, SparkLine, BarChart, LineChart, SegmentDisplay and TreeView, and the README points to drawing primitives with character and sub-character resolution for anyone writing a new widget. The TreeView entry is the newest of these and offers a hierarchical, collapsible view for nested data.

## Installing termdash and running a first widget

The README gives the install steps as a go get followed by a cd into the module path. Because this is a library, the practical first step is to pull it and then run one of the bundled demos, which are complete programs that exercise a single widget.

```bash
go get -u github.com/mum4k/termdash
cd github.com/mum4k/termdash
```

The module declares go 1.24.0 in go.mod, so a toolchain at least that new is needed. Once you are in the checkout, the gauge demo is a small target: it draws a progress bar and updates it, which shows the container, widget and redraw loop working together without the noise of a full dashboard.

```bash
go run widgets/gauge/gaugedemo/gaugedemo.go
```

You should see the terminal clear and a bordered gauge appear. The demo programs are the reference for wiring; the README says the usage of most elements is demonstrated in termdashdemo.go, and that file is the broadest example.

```bash
go run termdashdemo/termdashdemo.go
```

The README does not document an API reference inside the repository itself. It points to the Termdash wiki for all documentation and resources, and the public API surface is documented there. That split matters: the code examples in the repository show how to assemble things, but the contract for each widget lives outside the checkout.

## Where termdash will fight you

The README is direct about API stability, and it is the first thing to weigh. It states that there might still be breaking changes to the public API, at least until the project reaches version 1.0.0, and that any breaking changes will be published in the changelog. The latest release listed is v0.20.0 from 2024-03-10, so the 1.0.0 line has not been crossed. If you are building something you will not touch for a year, that is a real cost: an upgrade can require edits to your layout or widget calls, and the changelog is the only warning you get.

The second constraint is the private package boundary. The README says private packages can be identified by the presence of the /private/ directory in their import path, that their stability is not guaranteed, and that changes to them will not be backward compatible. Anything useful you find in private/ is fair game to break.

The third is scope. Termdash draws; it does not collect. There is no data source, no persistence, no alerting, and no remote access. A dashboard built with it lives and dies with the process that runs it, and it is visible only to whoever is attached to that terminal. If you need a dashboard several people can open in a browser, this is the wrong tool, and the README offers nothing that suggests otherwise.

## Termdash against termui and other terminal UI options

The README names gizak/termui as the project whose feature set inspired termdash, and describes termdash as a rewrite that focuses on code readability, maintainability and testability. That is the actual difference in approach: termui is the older lineage, and termdash was started to restructure the same idea around a documented public API, a design goals document and a high-level design document, both of which are referenced from the README. If you want the original, termui is the original. If you want the restructured one, with its own stated requirements, that is termdash.

There is a second axis worth separating. A library like termdash gives you drawing primitives and expects you to own the event loop and the data. Tools such as Grafterm and Uilive sit at a different level: they are programs built around terminal output rather than a widget toolkit you embed. Choosing between them is not a quality comparison, it is a question of whether you want to write Go code that assembles a UI or whether you want to run something that already does. Termdash only makes sense in the first case.

## Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-14, which is recent. That said, the release cadence is uneven: v0.18.0 landed on 2023-02-08, v0.19.0 on 2024-01-29 and v0.20.0 on 2024-03-10. Between releases the master branch can move, so pinning a version in go.mod is the safer default for anything you depend on, and reading CHANGELOG.md before bumping is the documented way to find breaking changes.

Upgrade cost is concentrated in two places: the public API, which the README says may still change before 1.0.0, and the dependency on github.com/gdamore/tcell/v2, whose own version bumps can change terminal behaviour underneath you. The go.mod also carries github.com/nsf/termbox-go and github.com/mattn/go-runewidth, so a dependency audit will pull in a few more modules than the widget count suggests.

The licence is Apache-2.0, as stated in the README badge and the LICENSE file at the repository root. Apache-2.0 is a permissive licence that includes an explicit patent grant and requires you to preserve notices and state changes. It is compatible with use in closed-source products. This is a description of the licence text, not legal advice; if you are redistributing a modified copy, read the terms yourself.

## Conclusion

Adopt termdash if you are writing a Go program that needs a live terminal UI and you are willing to build the data plumbing and the layout yourself; the demos under widgets/ and termdashdemo/ are the fastest way to judge whether its widget set fits. Do not adopt it if you want a dashboard you configure rather than code, or if you need a stable API today, since the README states there may be breaking changes to the public API until version 1.0.0 and the latest release is v0.20.0 from 2024-03-10. Before committing, run the demo that matches your hardest widget, check that your target terminal handles resizing and mouse events the way the demos do, and read the changelog for the breaking changes already recorded.

## FAQ

### Is termdash a program I can install, or a library I import?

It is a library. The README describes it as a cross-platform customizable terminal based dashboard, and the installation section is a go get of github.com/mum4k/termdash followed by a cd into the module path. The runnable programs in the repository are demos, not a distributable dashboard.

### What Go version does termdash require?

The go.mod file declares go 1.24.0, so a toolchain at least that new is needed to build the module.

### Which widgets ship with termdash?

The README lists Button, TextInput, Gauge, Pie, Donut, Text, SparkLine, BarChart, LineChart, SegmentDisplay and TreeView. Each has a demo program under widgets/ that the README names as the way to see it running.

### Is the termdash API stable enough for production use?

The README states there might still be breaking changes to the public API, at least until the project reaches version 1.0.0, and that breaking changes are published in the changelog. The latest release listed is v0.20.0 from 2024-03-10.

### Where is the termdash documentation?

The README points to the Termdash wiki for all documentation and resources, and says the public API surface is documented there. The repository itself carries design documents under doc/, including design goals, requirements and a high-level design.

## Sources

- [Issues](https://github.com/mum4k/termdash/issues)
- [License: Apache-2.0](https://github.com/mum4k/termdash/blob/master/LICENSE)
- [mum4k/termdash on GitHub](https://github.com/mum4k/termdash)
- [README](https://github.com/mum4k/termdash/blob/master/README.md)
- [Releases](https://github.com/mum4k/termdash/releases)

---

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