KMonad: layers and tap-hold on almost any keyboard
An advanced keyboard manager
At a glance
- What is it?
- KMonad brings QMK-style layers, multi-tap and tap-hold to almost any keyboard through low-level system manipulation. It is a Haskell project under the MIT licence, and its own README warns that the core maintainer may be absent for weeks at a time.
- Who is it for?
- KMonad suits people who already think in layers and tap-hold and want those behaviours on hardware that cannot run QMK, especially on Linux where the startup scripts and packaging are most developed. It is a poor fit if you need a graphical configuration tool, since the README points only to a tutorial file, a quick reference and community configurations, or if you depend on a maintainer who answers within days, given the disclaimer about chronic illness.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 108 days ago.
- What is it written in?
- Mainly Haskell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Why a keyboard manager exists at all
Most keyboards send whatever their firmware was built to send. If the firmware cannot be changed, the layout is fixed: Caps Lock stays Caps Lock, and the only escape is a remapper that runs on the host. KMonad targets exactly that gap. The README describes it as a tool that "lets you infinitely customize and extend the functionalities of almost any keyboard" by low-level system manipulations, which is a different proposition from editing a layout file that an application reads. The features it advertises are the ones usually associated with QMK-firmware enabled keyboards: layers, multi-tap, tap-hold and command buttons. The intended audience is someone who wants home-row modifiers, Space Cadet style Shift keys that produce parentheses when tapped, or a numbers layer on a small board, but who is not going to buy or build a programmable keyboard to get them. The project is written in Haskell, carries the MIT licence, and lists Linux, macOS and Windows among its topics.
Layers, tap-hold and command buttons as the core mechanism
The configuration model is the part worth understanding before installing anything. A layer is a set of keymaps assigned to the buttons of a keyboard, and the README states you can stack as many layers on top of a base layer as you want. When a layer is active, every keypress is interpreted according to that layer. That is how a 60% board can carry a QWERTY base, a Colemak or Dvorak alternative, a numbers and symbols layer, a function key layer and a mouse navigation layer at the same time. Multi-use buttons are the second mechanism. A single key can behave differently depending on whether it is tapped once, held, or tapped twice in quick succession. The README gives a concrete example: Caps Lock as Escape when pressed and released, Ctrl when held, and a layer switch when pressed twice quickly. The left and right Shift keys can produce parentheses on a tap and act as Shift when held. Command buttons go further and let a keypress trigger a shell command. All of this lives in a configuration file, and the project ships a tutorial at keymap/tutorial.kbd plus a quick reference at doc/quick-reference.md rather than a settings window.
Installing KMonad and writing a first configuration
The README does not inline installation instructions. It points to doc/installation.md for platform details, and the repository carries a nix/ directory, a startup/ directory with scripts for different init systems, and a Docker ignore file, which tells you the packaging story is broader than a single binary. Start by reading that installation document for your platform, then place a configuration file somewhere you control. The configuration language is a Lisp-like syntax, so the shape of a minimal file matters more than any single key name. The README points to keymap/tutorial.kbd for the language itself, and it is the only file in the repository that shows a full configuration, so read it before writing your own. If you want a working configuration rather than a blank page, the kmonad-contrib repository collects user configurations and accepts pull requests that add a subdirectory named after your GitHub username.
Where KMonad gets in the way
The most honest thing in the README is the disclaimer. The core maintainer describes being chronically ill with debilitating autoimmune symptoms that come and go, and states plainly that he might be gone for weeks on end, not from lack of interest but from lack of capacity. For a tool that sits between your keyboard and your operating system, that matters more than it would for a library. A bug that breaks input handling is not a cosmetic problem, and the release cadence reflects the situation: 0.4.3 in September 2024, 0.4.4 in April 2025, 0.4.5 in May 2026. The last push to the repository was on 2026-06-15. Another limitation is structural. KMonad works by low-level system manipulation, so it needs the privileges that come with reading input devices and creating virtual ones. On Linux that means access to device files and to uinput, which is why the project ships startup scripts and a GNOME Shell toggle extension rather than assuming it can just run. On Windows and macOS the same class of permission applies through different APIs. The README does not document rollback or a safe mode, so if a configuration makes your keyboard unusable you should know how to kill the process from another input device before you need to.
KMonad compared with QMK, Karabiner and keyd
The natural comparison is QMK. QMK runs on the keyboard's own microcontroller, so the remapping survives reboots, works on any host, and needs no software on the machine. KMonad runs on the host, so it works with keyboards that cannot be reflashed, but it depends on the operating system, on permissions, and on a process staying alive. If you already own a QMK-capable board, KMonad adds a layer of software you do not need. On macOS, Karabiner is the established host-side remapper; the difference in approach is that Karabiner is a macOS-only project, while KMonad aims at Linux, Windows and macOS from one configuration language. On Linux, keyd is the other common host-side option, and it takes a different route: it is a system service with its own configuration format rather than a Haskell program you launch with a file. The practical distinction is that KMonad's configuration language is the most expressive of the host-side tools, which is also why it has a tutorial file and editor modes for Emacs, Vim and VSCode instead of a form-based interface.
Licence, maintenance and the cost of upgrading
KMonad is MIT licensed, which is permissive and places few obligations on anyone who redistributes it or embeds it in a larger product. That is the whole of what the repository states about licensing; questions about your own compliance belong with a lawyer, not with this article. On maintenance, the facts are the release history and the disclaimer. Three releases in roughly twenty months, with the last push on 2026-06-15, and a maintainer who has said he may be unreachable for weeks. Upgrades are not free in the way a library upgrade is. The configuration language is the interface you depend on, and the repository keeps a changelog.md at the top level, so the first thing to check before moving to a new release is whether your configuration still parses. The README also distinguishes the master branch, which it calls the latest stable binary release, from develop, which it says is for the latest additions and tweaks and requires compiling your own binary. If you want stability, stay on released binaries and read the changelog; if you want a fix that has not shipped, you are building from source with the Haskell toolchain.
Editorial conclusion
KMonad suits people who already think in layers and tap-hold and want those behaviours on hardware that cannot run QMK, especially on Linux where the startup scripts and packaging are most developed. It is a poor fit if you need a graphical configuration tool, since the README points only to a tutorial file, a quick reference and community configurations, or if you depend on a maintainer who answers within days, given the disclaimer about chronic illness. Before adopting it, read doc/installation.md for your platform and confirm that the current release 0.4.5 covers your OS and init system.
Frequently asked questions
How do I use KMonad?
You write a configuration file in KMonad's Lisp-like language, describing a base layer and any layers above it, then run KMonad against that file. The README points to keymap/tutorial.kbd for the configuration language, doc/quick-reference.md for a condensed reference, and doc/installation.md for getting the binary onto your system.
Is KMonad safe?
The README does not make a safety claim either way. What it does state is that KMonad works by low-level system manipulation, which is why it needs access to input devices and, on Linux, to uinput, and why the repository ships startup scripts for different init systems. The README does not document a rollback or safe mode, so a broken configuration has to be handled by stopping the process.
How does KMonad compare with QMK?
QMK runs on the keyboard's own firmware, so the remapping is part of the hardware. KMonad runs on the host and provides the same class of features, which the README lists as layers, multi-tap, tap-hold and command buttons, through low-level system manipulation on a keyboard that cannot be reflashed.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/kmonad-kmonad)