WTF (wtfutil) review: a terminal dashboard built from configurable modules

What WTF is for, and who it is not for

WTF describes itself as "the personal information dashboard for your terminal, providing at-a-glance access to your very important but infrequently-needed stats and data." That phrasing is the whole design brief. The target user is a developer or ops person who keeps a terminal open all day and wants a low-frequency glance at things like pull requests, calendar entries, cloud account status or a feed, without switching to a browser tab. The word personal matters. There is no server component, no shared team view and no browser UI in the repository layout; the top-level entries are app/, cfg/, modules/, view/, wtf/ and a main.go, which is the shape of a single-user TUI binary. If your team needs a wall display that several people edit, or an authenticated web dashboard, this is the wrong tool and no amount of module configuration will change that.

How modules and config.yml drive the dashboard

The mechanism is a module registry. The README states that "modules are the chunks of functionality that make WTF useful" and that they are "added and configured by including their configuration values in your config.yml file." So the data flow is: start the binary, it reads config.yml, and for each configured module it instantiates the corresponding widget, which then polls its own external API or local source on its own schedule and renders into a grid. The repository supports this reading: modules/ holds the per-service code, cfg/ handles configuration, and view/ handles rendering, with rivo/tview and gdamore/tcell in go.mod as the terminal UI stack. Each module is therefore a plugin with its own auth requirements, its own refresh behaviour and its own documentation page. That is a genuine strength for breadth (DigitalOcean, GitHub, Google Calendar, HackerNews, Have I Been Pwned, NewRelic, OpsGenie, Security, Transmission and Trello are named in the README as starting points) and it is also the main operational cost, because you are configuring a dozen unrelated API integrations rather than one product.

Installing WTF on macOS, Linux or from source

The README lists several install paths. Homebrew is described as the simplest, with a tap for people who want releases sooner than homebrew-core accepts them. The go install path builds from the module path directly. There is also a standalone binary, MacPorts, and Arch User Repository packages (wtfutil for a source build, wtfutil-bin for pre-built binaries).

brew install wtfutil

wtfutil

With the tap instead of the core formula, the README gives this pair:

brew install linodians/tap/wtfutil

wtfutil

On a machine with a Go toolchain, the module install is one command:

 go install github.com/wtfutil/wtf@latest

If you download a release binary rather than using a package manager, the README says to copy it somewhere on your executable path and set the permissions:

chmod a+x /usr/local/bin/wtfutil

Running the binary with no further setup gives you the default dashboard; the real work is then writing config.yml. The README points at wtfutil.com/configuration/files/ for the file format and wtfutil.com/modules/ for each module's keys, and those pages are where the actual key names live. The README itself does not print a complete config.yml, so do not guess key names from this article: open the module page for the service you want and copy its example. From source, the README gives a Makefile route inside $GOPATH:

export GOPROXY="https://proxy.golang.org,direct"
export GOSUMDB=off
export GO111MODULE=on
go get -u github.com/wtfutil/wtf
cd $GOPATH/src/github.com/wtfutil/wtf
make install
make run

The Makefile in the repository defines build, install, run, lint, test and docker-build targets, so make run is the documented way to launch a locally built copy.

The maintenance model is the real limitation

The README is unusually direct about support: WTF is "open-source software, informally maintained by a small collection of volunteers who come and go at their leisure," and "there are absolutely no guarantees that, even if an issue is opened for them, bugs will be fixed or features added." The suggested remedy is a bounty on BountySource. The last push to the repository was on 2026-09-17 and the most recent release listed is v0.50.0 from 2026-06-30, so the project is not abandoned, but the governance model is the thing to price in. A module that talks to a third-party API you depend on can break when that API changes, and the README gives you no timeline for a fix. The second limitation is the pending rename: the README carries a warning that the project is "going through some changes as we prepare for v1.0," including "a rename from WTF to Tessera." Anything you automate around the wtfutil binary name, the module path github.com/wtfutil/wtf, or the Homebrew formula is a moving target until that lands. Third, because modules poll external services, each one you enable is another credential on disk and another source of rate limits and refresh failures; the README does not describe a shared caching layer or a failure policy for a module whose API is down.

WTF compared with writing your own shell dashboard

The obvious alternative is a hand-rolled script: a tmux layout running watch on a few curl calls, or a small Go or Python program that prints what you care about. The difference in approach is configuration versus code. With a script you own every line and every failure, and you can shape output exactly; with WTF you inherit a module's implementation, its auth flow and its refresh semantics, and you get a rendering grid, a config file format and roughly a hundred service integrations you did not write. The trade is real in both directions. A script never surprises you with a rename to Tessera, and it never gives you a NewRelic or OpsGenie widget for the cost of a few YAML keys. If you only ever wanted one number on screen, the script wins. If you want eight services from eight different vendors in one pane, the config-file route is less work than eight scripts.

Licence and upgrade cost

WTF is licensed MPL-2.0, per the repository badge and LICENSE.md. MPL-2.0 is a file-level copyleft licence: modifications to files already covered by it stay under it, while larger works that combine it with other code can be distributed under other terms. If you fork a module to fix it, read the licence text rather than this summary; nothing here is legal advice. On upgrades, the practical cost is that a config.yml written against one release may need edits when a module's keys change, and the README offers no migration notes. The release history shows a steady cadence (v0.49.0 in February 2026, v0.49.1 in April, v0.50.0 in June), so a pinned version is the sane default for a dashboard you rely on daily. Note also that the README tells contributors and sponsors how to change the exit message shown when quitting, which is a small sign of how much of the project is personality-driven rather than product-driven.

Editorial conclusion

Adopt WTF if you already live in a terminal and want GitHub, calendar, feed or cloud status data in one pane without leaving it; skip it if you need a hosted, multi-user dashboard with a support contract, because the README describes a small volunteer project with no guarantee that bugs get fixed. Before committing, verify that the modules you actually need are documented at wtfutil.com/modules, check whether the Homebrew formula or the linodians/tap version matches the release you want, and read the v1.0 rename notice: the project says it is preparing to rename WTF to Tessera, so pin a version and expect the name and binary to change under you.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. wtfutil/wtf on GitHub