# niri: a scrollable-tiling Wayland compositor where windows never resize

> niri arranges windows in columns on an infinite horizontal strip, one strip per monitor, with dynamic workspaces stacked vertically. This is a practical look at what that model changes, how to install it on Fedora or NixOS, and where it stops being the right tool.

**niri-wm/niri** — A scrollable-tiling Wayland compositor.

- Repository: https://github.com/niri-wm/niri
- Website: https://niri-wm.github.io/niri/
- Stars: 28,040 · Forks: 1,167
- Language: Rust
- License: GPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/niri-wm-niri

## The layout problem niri is built to remove

In a classic tiling compositor, opening a window resizes every other window on the workspace. That is the defining behavior of the model, and it is also what makes a working layout feel unstable: you arrange three windows, open a fourth, and the three you had are now narrower. niri starts from the opposite premise. Windows are arranged in columns on an infinite strip going to the right, and the README states plainly that opening a new window never causes existing windows to resize. New windows land off-screen to the right. You scroll to them.

The audience follows from that. niri suits people who keep a working set of windows open for hours and treat the screen as a viewport onto a longer list rather than a fixed grid. It is a Wayland compositor written in Rust, so it is not a drop-in replacement for an X11 window manager, and it is not a desktop environment. The README is direct about this: niri by itself is not a complete desktop environment, and it points to shells like DankMaterialShell or Noctalia, or to building a more traditional setup. If you want a bar, a launcher and a notification daemon decided for you, niri is the wrong starting point.

## How the strip, workspaces and monitors fit together

The mechanism is spatial and easy to reason about once you accept two axes. Horizontally, each workspace is a strip of columns that extends indefinitely to the right. Vertically, workspaces are dynamic and arranged in a stack, with an empty workspace always present at the bottom, in the style of GNOME. Moving between workspaces is a vertical motion; moving within one is horizontal scrolling.

Monitors are the part niri treats more strictly than most. Every monitor has its own separate window strip, and the README states that windows can never overflow onto an adjacent monitor. Each monitor also has an independent set of workspaces. This is a deliberate contrast with PaperWM, the GNOME Shell extension that inspired niri: because PaperWM is an extension, it has to work against Shell's global window coordinate space to stop windows from spilling across screens. Writing a compositor let niri separate the monitors properly instead of fighting an existing coordinate model.

The arrangement survives hardware changes, with a caveat worth reading twice. Disconnect a monitor and its workspaces move to another monitor. Reconnect it and they move back. The README qualifies this as happening where it makes sense, which is honest but not a specification. If your workflow depends on exact workspace placement across docking cycles, that sentence is the limit of what the documentation promises.

## Installing niri on Fedora or NixOS and opening a first window

The README does not carry install instructions inline. It points to the Getting Started page on the project site for the actual steps, and the repository ships a flake.nix at the top level plus niri.spec.rpkg, which indicates Nix and RPM-based packaging paths. The related searches around Niri Fedora and Niri NixOS reflect those two routes. Because the exact package commands are not in the README, treat the following as the shape of the workflow rather than a verified transcript, and confirm each command against the Getting Started page.

On NixOS, the repository's flake is the entry point. Adding the flake as an input is the documented shape of a Nix install:

```nix
{
  inputs.niri.url = "github:niri-wm/niri";
}
```

On Fedora, the presence of niri.spec.rpkg in the repository root means the project maintains an RPM spec file. Check whether your Fedora release carries a niri package before building from that spec, since building a compositor from source pulls in the Smithay dependency pinned in Cargo.toml.

Building from source is the fallback, and it has a hard floor: Cargo.toml sets rust-version to 1.87. The workspace also pins Smithay to a specific git revision rather than a crates.io version, so a build resolves that commit:

```bash
git clone https://github.com/niri-wm/niri
cd niri
cargo build --release
```

Once you are running niri, configuration is live-reloading, which changes how you work. You edit the config file and the running compositor picks up the change without a restart. Layout options named in the README include gaps, borders, struts and window sizes, plus gradient borders with Oklab and Oklch support. Start from the default configuration and change one value at a time; because reload is live, a malformed edit is visible immediately rather than at next login.

## Where niri is the wrong tool

The scrollable model has a cost that the README does not dwell on: a long strip is easy to get lost in. The Overview, which zooms out on workspaces and windows, exists partly because of this. If you habitually run five windows side by side and want them all visible at once, the infinite strip works against you, and you will spend time scrolling rather than looking. Traditional tiling is better for that shape of work.

Two documented gaps matter more concretely. First, touchscreen gestures are not implemented. The README says niri supports tablets, touchpads and touchscreens, that you can map a tablet to a specific monitor, and that there are touchpad gestures, but no touchscreen gestures yet. A tablet-first workflow is fine; a touchscreen-first one is not.

Second, the IPC surface is explicitly unstable. The repository contains an niri-ipc workspace member, and the README's Status section carries a note that niri-ipc does not have a stable API. Anything you build against that interface, including status bars and scripts, can break on upgrade. That is a real constraint for anyone planning to write tooling, and it is the kind of thing that is easy to discover after the fact.

Screencasting has a specific dependency worth noting as well. Monitor and window casting goes through xdg-desktop-portal-gnome rather than a niri-specific portal, and Xwayland is integrated via xwayland-satellite starting from niri 25.08. If your workflow depends on an X11 application behaving exactly as it did under a different compositor, that integration path is the thing to test first.

## niri compared with Hyprland and PaperWM

The comparison people actually search for is niri against Hyprland, and the difference is in the layout model rather than in features. Hyprland is a dynamic tiling compositor in the conventional sense: windows share the screen and reflow as you open and close them. niri does not reflow. A new window appears at the end of the strip and existing windows keep their widths. If you like the reflow, niri will feel like it is refusing to do the obvious thing. If the reflow is what annoys you, that is the whole argument for switching.

The closer comparison is PaperWM, which niri names as its main inspiration. PaperWM implements scrollable tiling as a GNOME Shell extension, so it inherits Shell's global window coordinate space and, per the README, has to work against it to keep windows from overflowing between monitors. niri is a compositor, so monitor separation is a design property rather than a workaround. The trade-off runs the other way too: as an extension, PaperWM lives inside a full GNOME session with all the shell components already present. niri gives you the compositor and leaves the rest to you. The README also lists karousel for KDE, plus scroll and papersway, as other projects implementing a similar workflow, so the scrollable idea is not unique to niri even though niri is the one that builds it into a compositor.

## Maintenance, licensing and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-20. Releases have landed on a rough cadence of three per year: v25.08 on 2025-08-30, v25.11 on 2025-11-29, and v26.04 on 2026-04-25. The workspace version in Cargo.toml is 26.4.0, matching the v26.04 release. That is a steady enough rhythm to plan around, and the release notes are the place to check before upgrading, since the README does not document a rollback procedure.

The licence is GPL-3.0-or-later per Cargo.toml, and the repository LICENSE file is GPL-3.0. The or-later part matters if you plan to reuse code: it permits distributing under a later GPL version. For ordinary desktop use the licence is not a practical concern. For anyone embedding niri or its crates in another product, GPL-3.0-or-later is a copyleft licence and the obligations differ from permissive ones, so read the licence text rather than this summary. Nothing here is legal advice.

Upgrade cost is dominated by two things. The Rust floor moves with the toolchain, currently 1.87, so a build machine on an older toolchain will fail before it reaches your code. And because niri-ipc has no stable API, any bar or script you maintain against it is the part of your setup most likely to need attention after a release. The compositor config itself reloads live, which makes layout changes cheap to iterate on, but that says nothing about whether a config key survives a version bump.

## Conclusion

Adopt niri if you want a tiling compositor whose layout never reflows under you, and you are willing to assemble the rest of the desktop yourself. Skip it if you need a complete out-of-the-box environment, touchscreen gestures, or a stable IPC surface, since niri-ipc ships without compatibility guarantees. Verify first that your distribution packages niri or that you can build it against Rust 1.87, and read the Getting Started page before touching the config.

## FAQ

### What is niri?

niri is a scrollable-tiling Wayland compositor written in Rust. Windows are arranged in columns on an infinite strip going to the right, and opening a new window never resizes the existing ones.

### Is niri a good WM?

The README states that niri is stable for day-to-day use and does most things expected of a Wayland compositor, and that many people daily-drive it. Whether it suits you depends on the layout model: if you do not want windows to reflow when a new one opens, that is the point of niri.

### Which is better for me, niri or Hyprland?

The difference is the layout model. Hyprland reflows windows as you open and close them; niri keeps existing windows at their width and puts new ones further along an infinite strip. Pick niri if the reflow is what bothers you, and Hyprland if you want the conventional tiling behavior.

### How to use niri?

Follow the Getting Started page linked from the README, then configure layout options such as gaps, borders, struts and window sizes. Configuration is live-reloading, so edits apply without restarting the compositor. You will also need a desktop shell, since niri by itself is not a complete desktop environment.

## Sources

- [License: GPL-3.0](https://github.com/niri-wm/niri/blob/main/LICENSE)
- [niri-wm/niri on GitHub](https://github.com/niri-wm/niri)
- [Project website](https://niri-wm.github.io/niri/)
- [README](https://github.com/niri-wm/niri/blob/main/README.md)
- [Releases](https://github.com/niri-wm/niri/releases)

---

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