Conky: a lightweight system monitor you configure, not install and forget

What Conky solves, and who it is actually for

Conky draws system information directly onto the desktop. The README describes it as a free, light-weight system monitor for X that "displays any kind of information on your desktop", and lists the same job for Wayland, macOS, the console, a file, and HTTP output. That last part matters more than the desktop-painting part: the same binary can render a widget and serve the same numbers over HTTP, because the HTTP output path is a build option rather than a separate program.

The intended user is someone who already knows what they want to see and is willing to write it down. Conky does not ship a settings dialog. Its configuration is a file, and the README's install instructions end by telling you to create one. If your idea of a monitor is a tray icon that appears after an installer finishes, Conky is the wrong shape. If you want a fixed set of numbers in a fixed place, with fonts, colours, progress bars and graph widgets, the project is aimed at you.

The second audience is people who have outgrown those widgets. Conky exposes more than 300 built-in objects, and the README lists built-in IMAP and POP3 support, music player integration for MPD, XMMS2 and Audacious, and Lua as the extension path with Imlib2 and Cairo bindings. That is a scripting host wearing a monitor's clothes.

How Conky works: a config file, an object list, and an output backend

The architecture visible in the repository is a C++ core that parses a config, evaluates text objects, and hands the result to a drawing backend. The README's feature list maps onto that: OS stats such as uname, uptime, CPU usage, memory usage, disk usage and network monitoring are built-in objects, and the display layer can render them as text, progress bars or graph widgets.

The config is the program. Objects are written into the config as text, and Conky substitutes their current values each update. Anything the built-in objects do not cover is meant to be reached through Lua or through an external script or program, which the README lists as an extension route. Lua is not a side feature here: the Dockerfile builds separate Lua bindings for Cairo, Cairo XLIB, Imlib2, RSVG and text, so the drawing primitives are exposed to Lua as distinct compile-time units.

Output is a backend choice, not a separate tool. The README lists X, Wayland, macOS, console, file and HTTP as places Conky can send its output. In the Dockerfile, HTTP is switched on with -DBUILD_HTTP=ON and Wayland with -DBUILD_WAYLAND=OFF, which is the clearest evidence that these are not all present in every binary. If a build omits a backend, no config setting will bring it back.

Installing Conky with the AppImage and running a first config

The README says many package managers already include Conky, and that the AppImage or the Nix flake are the way to get the latest version. The AppImage route is the shortest one that does not depend on your distribution's packaging. Download the AppImage from the releases page, then make it executable, generate a config, and run it. The README gives exactly these three commands:

chmod +x ./conky-*.AppImage        # make it executable
./conky-*.AppImage -C > ~/.conkyrc # create a default config
./conky-*.AppImage                 # run

The first command sets the executable bit. The second runs Conky with -C and redirects its output into ~/.conkyrc, which is how a default config is produced rather than hand-written. The third starts it with that file in place. The README adds a note that the AppImage may need additional runtime libraries installed, so a launch that fails immediately is more likely a missing library than a bad config.

For a Nix setup, the README shows the flake as an input rather than a command:

{
  inputs = {
    conky.url = "github:brndnmtthws/conky";
  };
}

After adding that input, the README says to use inputs.conky.packages.${system}.default, or inputs.conky.packages.${system}.conky for versions up to v1.19.8. It also notes that a Nix package exists in nixpkgs with more configuration options, though it is not always up to date with the newest release. If you are building from source instead, the README documents a mise-based developer setup: run mise install and mise run doctor from the repository root, where doctor checks for system libraries such as X11, Cairo, Lua, Imlib2, librsvg, ncurses and libxml2, then use mise run configure, mise run build and mise run test.

Wayland, missing libraries, and the cases where Conky is the wrong tool

The README is direct about Wayland: Conky "can also run on Wayland (with caveats)". It does not enumerate those caveats in the README, and the wiki is where configuration detail is said to live. Treat that as the project's own signal that Wayland support is the less-travelled path. On a Wayland session, the safest assumption is that some of what works under X will not, and that you will be reading the wiki rather than the README to find out which.

The Dockerfile is the second warning. It builds Conky with a long list of options, including -DBUILD_HTTP=ON, -DBUILD_IRC=ON, -DBUILD_MYSQL=ON, -DBUILD_NVIDIA=ON, -DBUILD_PULSEAUDIO=ON and -DBUILD_WAYLAND=OFF, and it carries an X11 build argument that selects between two cmake invocations. That means the Conky you install is the Conky someone else configured. A distribution package that omits the NVIDIA or PulseAudio option will not show those values, and no amount of editing the config will change it. When a documented object returns nothing, check the build flags before rewriting the config.

Conky is also the wrong tool when the information needs to leave the machine in a structured, reliable way. It can write to a file or serve HTTP, but those are display backends for a rendered widget, not a metrics pipeline. If you need queryable time series, retention and alerting, a monitor that paints text onto a desktop is the wrong layer, even if the numbers are the same.

Conky compared with a terminal dashboard such as btop

The closest everyday alternative is a terminal dashboard in the style of btop or htop: a program that draws CPU, memory, disk and process statistics in a terminal window, with a layout the program chose and keys to change it. The difference is where the configuration lives. A terminal dashboard gives you a fixed layout and a keybinding to reorder or filter it. Conky gives you a text file and expects you to describe the layout yourself, which is why the README can advertise fonts, colours, progress bars, graph widgets and mouse events rather than a set of panels.

That trade runs in both directions. A terminal dashboard works over SSH and inside tmux, and it needs no compositor, no X or Wayland session and no font configuration. Conky needs a display to draw on, which is exactly why its README lists console output as a separate mode rather than the default. If you administer remote machines, the terminal tool is the better fit. If you want the numbers embedded in a desktop you already look at all day, and you want to control the typography and placement, Conky is the one that lets you.

Conky's other distinguishing feature is the extension path. The README lists Lua with Imlib2 and Cairo bindings, plus the option to call your own scripts and programs. A terminal dashboard is a closed set of panels. Conky is a renderer you can extend, which is also why it takes longer to set up.

Maintenance, licensing and what upgrading costs you

The repository is not archived, and its last push was on 2026-08-07, so the project is still receiving commits. Recent releases are v1.24.2 on 2026-06-19, v1.24.1 on 2026-06-17 and v1.24.0 on 2026-06-01. The version numbers matter for one practical reason: the README ties a packaging detail to a version, saying the Nix flake has been available since Conky v1.17.0 and that inputs.conky.packages.${system}.conky is the name to use for versions up to v1.19.8. Anyone copying an older flake snippet onto a newer release will get an evaluation error rather than a build.

Upgrade cost is mostly the config, not the binary. The README does not document a config migration path or a compatibility guarantee between releases, and it does not document rollback. A config that works on one release is not promised to work on the next, so keeping your conkyrc in version control is the cheap insurance. The AppImage makes trying a new release low-risk, because you can run it alongside the packaged version and compare.

Conky is licensed under GPLv3, with the repository also carrying a LICENSE.BSD file. GPLv3 is a copyleft licence: if you distribute a modified Conky, the terms of that licence apply to what you distribute. Running it on your own desktop and editing your own config is not distribution. If you plan to ship Conky inside a product, read the licence text and the LICENSE.BSD file yourself; this is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt Conky if you want a desktop monitor whose layout lives in a text file you can version and copy between machines, and if you are willing to learn the config format. Do not adopt it if you want a settings window: the README points at the wiki and conky.cc for configuration, and there is no GUI in the repository. Before committing, verify that your compositor is supported, since the README says Wayland runs only with caveats, and check which build options your distribution's package enables, because the Dockerfile shows features such as HTTP, IRC, MySQL and NVIDIA are compile-time choices rather than things you can turn on at runtime.

Frequently asked questions

Official sources

1. brndnmtthws/conky on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases