GlazeWM: a keyboard-driven tiling window manager for Windows

The workspace problem GlazeWM is built to solve

Windows has no first-class notion of a tiling layout. You get snap zones, virtual desktops and a lot of manual dragging. GlazeWM replaces that with the model i3wm users already know: windows are placed into a tree, focus moves by direction, and workspaces are switched by command rather than by clicking. The README describes it as "a tiling window manager for Windows inspired by i3wm" and says it "lets you easily organize windows and adjust their layout on the fly by using keyboard-driven commands."

The audience is narrow and specific. This is for people who already use keyboard-driven window management, or who want to learn it, and who are willing to write YAML to get it. It is not for someone who wants a smarter version of snap assist, and it is not for someone who does not want to memorise bindings. The project also lists multi-monitor support and customizable rules for specific windows, which is where a tiling manager either becomes usable daily or becomes a constant fight with apps that refuse to be tiled.

One framing point the README makes early: the project is at v3, and the release history shows v3.10.1 on 2026-03-21 and v3.10.0 on 2026-03-16, with v3.9.1 back on 2025-06-18. The most recent push to the default branch was 2026-06-20. That is a project that ships, but the gap between v3.9.1 and v3.10.0 is worth noting if you are deciding when to upgrade.

How the tiling model and config actually connect

The architecture visible in the repository is a Rust workspace. Cargo.toml declares members as packages/*, with default-members set to packages/wm and packages/wm-cli. That split matters: there is a window manager crate and a separate CLI crate, and the CLI is the thing you invoke. The README's custom-config example runs ./glazewm.exe start --config="C:\<PATH_TO_CONFIG>\config.yaml", which confirms start is a subcommand of the CLI rather than a flag on the main binary.

Configuration is YAML, and the README says the default config is generated at %userprofile%\.glzr\glazewm\config.yaml. The top-level keys shown are general and keybindings. Under general you get startup_commands, shutdown_commands and config_reload_commands, which are the hooks that let you launch a status bar or a script when the WM starts, and clean up when it stops. There is also focus_follows_cursor, toggle_workspace_on_refocus, and a cursor_jump block with an enabled flag and a trigger that accepts either "monitor_focus" or "window_focus".

Keybindings are a list. Each entry has commands and bindings. Commands are strings that look like the CLI surface: "focus --workspace 1" or "move --workspace 1". A single binding can run several commands in sequence, which the README illustrates by moving a window to workspace 1 and then focusing workspace 1 from one key press. That is the whole data flow: key press, binding match, command list, window manager state change. The workspace dependencies in Cargo.toml include tokio and tokio-tungstenite, which points at an async runtime and a WebSocket client, consistent with the documented Zebar integration for a status bar.

Installing GlazeWM and writing your first binding

The README points at the releases page for the latest version and also documents three package managers. On Windows, winget is the shortest path:

winget install GlazeWM

Chocolatey and Scoop are documented as well. For Scoop you need the extras bucket first:

scoop bucket add extras
scoop install extras/glazewm

After installation, the README says a default configuration can optionally be generated on first launch. That file lands at %userprofile%\.glzr\glazewm\config.yaml. Open it before you start rebinding anything, because it is the closest thing this project has to a complete command reference.

To move the config somewhere else, either pass the path on start or set an environment variable. The README gives both forms:

./glazewm.exe start --config="C:\<PATH_TO_CONFIG>\config.yaml"
setx GLAZEWM_CONFIG_PATH "C:\<PATH_TO_CONFIG>\config.yaml"

The stated benefit of a custom path is that you can name the file something else, such as glazewm.yaml. A minimal keybinding entry, following the README's shape, looks like this:

keybindings:
  - commands: ["focus --workspace 1"]
    bindings: ["alt+1"]
  - commands: ["move --workspace 1", "focus --workspace 1"]
    bindings: ["alt+shift+1"]

Save the file and reload. The README lists config_reload_commands as the hook that runs after the config has reloaded, so if you put something there you should see it fire on each reload.

The Windows key is not a usable modifier, and the README says so

The README states plainly that it is "recommended to use the alt key for keybindings" and that the Windows key "is unfortunately a pain to remap, since the OS reserves certain keybindings (e.g. lwin+l)." This is the single most important constraint in the project, and it is a constraint of the platform rather than the code. People coming from i3wm or from a macOS setup expect the Super key to be the modifier. On Windows, that habit collides with OS-reserved combinations, and the project's answer is to tell you to use alt instead.

The second limitation is documentation surface. The README has a section headed Config documentation, but what it contains is a partial sample: general and keybindings, plus a table of usable key names. It does not enumerate the full command set in the README itself. The README points at resources/assets/sample-config.yaml for the default config and at a cheat sheet image for default bindings. If you want to know whether a command exists, the reliable answer is in the sample config or the CLI, not in the prose. That is a real cost for anyone evaluating the tool before installing it.

A third case where GlazeWM is the wrong tool: if you want a status bar, it is not included. The README lists integration with Zebar as a feature, and Zebar can optionally be installed via a checkbox during installation. If you use a different bar, the general block's startup_commands and shutdown_commands are the documented mechanism for starting and stopping it alongside the WM. The search questions about using GlazeWM without Zebar or with Yasb point at exactly this gap.

GlazeWM compared with komorebi and with i3wm itself

The most common comparison for GlazeWM is komorebi, another tiling window manager for Windows. The difference in approach that the documentation supports is configuration format and integration surface. GlazeWM's README leads with "Simple YAML configuration," and its config is a single YAML file with general and keybindings at the top level. Its status bar story is a first-party companion, Zebar, offered as a checkbox during installation, with a WebSocket client in the dependency list to support that integration. If you want one vendor for the WM and the bar, and you want to edit YAML, GlazeWM is the more consolidated choice.

Against i3wm itself, the comparison is not feature parity so much as platform. i3wm runs on X11, and GlazeWM is a Windows program that borrows the interaction model. The README says "inspired by i3wm" rather than compatible with it, and nothing in the README suggests config or command compatibility. The search question asking how GlazeWM compares to i3 is best answered by saying the mental model transfers and the configuration does not.

On macOS, the repository description and topics mention macOS, and the project name appears in searches like "glazewm macos." The README, however, is written entirely around Windows: the install commands are winget, Chocolatey and Scoop, the config path is a Windows user profile path, and the executable is glazewm.exe. Treat macOS as unconfirmed by the documentation you can read before installing.

Licence, upgrade path and the cost of keeping up

GlazeWM is licensed under GPL-3.0, and the repository contains LICENSE.md at the top level. For an end user running the binary on a personal machine, that is not a practical concern. For anyone embedding GlazeWM in a product, or shipping a modified build, the copyleft terms are the thing to read in full, and this article cannot substitute for that reading.

Upgrade cost is mostly a config question. The release history shows v3.9.1 in June 2025 and then v3.10.0 and v3.10.1 in March 2026, so the project can go many months between feature releases. The README does not document rollback, and it does not describe a config migration tool. That means an upgrade is: install the new build, start it, and see whether your YAML still parses and your bindings still resolve. The config_reload_commands hook is the only reload-related mechanism the README names, and it runs after a reload rather than validating one.

There is also a maintenance signal in the repository itself. The last push to the default branch was on 2026-06-20. The repository is not archived. Whether that cadence suits you depends on how much you need fixes to land quickly; the release spacing above is the more useful number for planning.

Editorial conclusion

Adopt GlazeWM if you already work in workspaces and want to drive window layout from the keyboard on Windows, and if you accept that the Windows key is a poor binding target and that the docs live mostly in the sample config. Do not adopt it if you want a macOS build today, or if you expect the README to walk you through every command and failure mode. Before installing, read resources/assets/sample-config.yaml and check which commands your intended bindings map to, because the config is the manual.

Frequently asked questions

Official sources

1. glzr-io/glazewm on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases