# Zellij: A Terminal Workspace Built Around Layouts and WebAssembly Plugins

> Zellij is a Rust terminal multiplexer with a built-in status bar, a layout file format called KDL, and plugins compiled to WebAssembly. It solves the first-run problem that tmux leaves to the user, but it also asks you to learn a second configuration language. This review covers what the README and repository actually document, including the Windows story and the pre-release branch warning.

**zellij-org/zellij** — A terminal workspace with batteries included

- Repository: https://github.com/zellij-org/zellij
- Website: https://zellij.dev
- Stars: 35,616 · Forks: 1,470
- Language: Rust
- License: MIT
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/zellij-org-zellij

## The problem Zellij targets: multiplexing without a config file first

Terminal multiplexers have historically been configured before they are usable. The README frames Zellij's design philosophy as not sacrificing simplicity for power, and it claims a good experience out of the box alongside advanced features. That is a direct answer to the usual first hour with tmux, where you open a session and nothing on screen tells you which key enters command mode.

Zellij's audience is stated plainly: developers, ops-oriented people, and anyone who loves the terminal. The README says it is geared toward beginner and power users alike. Those two groups want different things, and the project's bet is that a status bar and a layout file can serve both. Whether that holds depends on how much you value discovering keybindings visually versus defining them yourself.

The second half of the pitch is less common among multiplexers: true multiplayer collaboration, floating and stacked panes, and a plugin system where plugins can be written in any language that compiles to WebAssembly. A built-in web client is also listed, which the README says makes a terminal optional. That combination is the actual differentiator, not the pane splitting itself.

## How Zellij is put together: a workspace of crates and WebAssembly plugins

The repository is a Cargo workspace. The root package named zellij depends on three path crates: zellij-client, zellij-server, and zellij-utils. That split is visible in the top-level directory listing, which also contains zellij-tile, zellij-tile-utils, and zellij-integration-tests. In practice this means the client that talks to your terminal, the server that owns sessions and panes, and the shared utilities are separate compilation units, and the tile crates are the interface plugins build against.

The workspace members list is dominated by default-plugins. Entries include compact-bar, status-bar, tab-bar, strider, session-manager, configuration, plugin-manager, about, share, multiple-select, layout-manager, and link. Those are the pieces you see when Zellij starts: the bars, the session switcher, the layout picker. They are plugins, not hardcoded UI, which is why the plugin system is central rather than an add-on.

Configuration is not done in the repository's own format. The example directory holds config.kdl, default.kdl, alt-centered-config.kdl, a layouts directory, a themes directory, and screen-overview.yaml. KDL is the configuration language, and the README points readers to the configuration documentation on zellij.dev rather than describing keys inline. That is a real cost: the README alone will not tell you how to write a layout.

The repository also includes a docker-compose.yml that is not a deployment recipe. It defines a single service, zellij-e2e, using the image ghcr.io/linuxserver/openssh-server with container name zellij-e2e and hostname zellij-e2e. It sets PUID and PGID to 1000, TZ to Europe/Vienna, PASSWORD_ACCESS to true, USER_PASSWORD to test, and USER_NAME to test. It bind-mounts ./target to /usr/src/zellij and ./src/tests/fixtures to /usr/src/zellij/fixtures, and publishes 127.0.0.1:2222:2222/tcp. That is an SSH target for end-to-end tests, not something you run to use Zellij.

## Installing Zellij and opening your first session

The README's recommended path is a package for your operating system, listed in docs/THIRD_PARTY_INSTALL.md. That file is the authoritative source for distro-specific instructions, and the README does not reproduce them. If no package exists for your platform, the README offers two fallbacks: download a prebuilt binary from the latest release and place it in $PATH, or compile from source with cargo.

The cargo route is a single command. The README gives it exactly as follows.

```bash
cargo install --locked zellij
```

The --locked flag is not decorative. It tells Cargo to use the versions recorded in Cargo.lock, so you get the dependency set the maintainers tested against rather than the newest compatible crates. Expect a Rust toolchain and a compile step, not a downloaded binary.

If you want to evaluate Zellij before installing anything, the README documents a launch script for bash and zsh.

```bash
bash <(curl -L https://zellij.dev/launch)
```

For fish and xonsh the README gives a different form, because process substitution is not available in those shells.

```bash
bash -c 'bash <(curl -L https://zellij.dev/launch)'
```

Both run a script fetched over the network, so the usual caveat applies: you are executing remote code, and the README does not describe what the script does beyond launching Zellij.

Once installed, the README does not walk through a first session. It redirects to the screencasts and tutorials page at zellij.dev/screencasts. That is a documentation gap worth naming: the installation section is concrete, and the usage section is a link. The example/config.kdl and example/layouts files in the repository are the closest thing to a worked example inside the repo itself.

If you are building from source rather than installing, the README gives development commands. Clone the project, then for debug builds run cargo xtask run, and to run all tests run cargo xtask test. CONTRIBUTING.md holds the rest of the build commands.

## The main branch warning, and why it matters more than it looks

The README states that installing from main is not recommended. It describes that branch as pre-release code, constantly worked on, and possibly containing broken or unusable features. It goes further: using it may corrupt the cache for future versions, forcing users to clear it before they can use the officially released version.

That last sentence is the part to take seriously. A cache format that can be invalidated by running an unreleased build means the cost of trying main is not limited to a crash. You may need to clear state before a released version works again, and the README does not document a rollback procedure or name the cache path. If you are evaluating Zellij for a team, pin to a release.

The release cadence visible in the repository supports pinning. v0.45.1 was released on 2026-08-28, v0.45.0 on 2026-08-20, and v0.44.3 on 2026-05-13. The last push to the repository was on 2026-08-28, the same day as v0.45.1, and the repository is not archived. Two releases eight days apart suggests the 0.45 line needed a quick follow-up, which is normal for a project at this stage but is also a reason not to track main.

The Cargo.toml compounds this. The root package depends on zellij-client and zellij-server at version 0.46.0, while the newest published release is v0.45.1. The workspace is already versioned ahead of the release, which is exactly what you would expect from a project that develops on main and tags releases, and exactly why the README's warning is not boilerplate.

## Where Zellij is the wrong tool

The most concrete limitation is Windows. The search data shows people asking how to use Zellij on Windows, and the README does not offer a Windows installation path. It points to OS packages, prebuilt binaries, or cargo. The repository does contain a wix directory, which is the Windows Installer XML toolset, and Cargo.toml has a Windows-only build dependency on embed-resource version 3. Those facts indicate Windows is built and packaged somewhere in the pipeline, but the README does not document an end-user Windows install, and it does not mention WSL. Treat Windows as unverified from the README alone.

The second limitation is configuration language overhead. If you already have a working tmux.conf, Zellij does not read it. You rewrite layouts, keybindings and themes in KDL, and the README sends you to zellij.dev for the syntax. The example directory gives you files to copy, but copying is not the same as understanding, and a layout that references a theme you have not defined will fail in ways the README does not describe.

The third is plugin API stability. The README promotes plugins in any language that compiles to WebAssembly, and the default plugins are workspace members compiled alongside the binary. That coupling means plugin authors track Zellij's own release train. Nothing in the README promises a stable plugin ABI, and the 0.x version numbers are consistent with that.

Finally, the README's own note on issues is worth reading before you judge the project by its tracker. It states that issues, open or closed, do not necessarily indicate a problem or bug in the software, and that maintainers cannot promise every report will be dealt with or even read. That is unusually candid, and it means issue volume is not a signal either way.

## Zellij compared with tmux, and what the difference actually is

The comparison people search for is Zellij versus tmux, and the honest answer from the README is about defaults, not capability. Both are terminal multiplexers. tmux gives you a blank session and expects you to know its prefix key. Zellij ships a status bar and tab bar as default plugins, so the interface tells you what is available. That is the out-of-the-box experience the README claims.

The deeper difference is the extension model. tmux configuration is a scripting language evaluated at startup, and its ecosystem is shell scripts and plugins managed by third-party tools. Zellij's extensions are WebAssembly modules built against the zellij-tile crate, and the default plugins are themselves workspace members. That means a Zellij plugin is a compiled artifact with a defined interface rather than a script, which is a heavier build process and a tighter coupling to the host version.

Layouts are the other divergence. Zellij's KDL layout files describe panes, tabs and plugins declaratively, and the repository ships example/layouts to copy from. tmux has no equivalent first-class concept; you approximate it with scripts that issue split-window commands. If your workflow is a fixed arrangement of panes you recreate every morning, Zellij's layout file is the feature that pays for the learning curve. If your workflow is ad hoc, the built-in bars are the part you will notice.

The multiplayer and web client features have no direct tmux counterpart in the README's description. tmux supports multiple clients attached to one session, but the README describes Zellij's collaboration as true multiplayer, and the web client as making a terminal optional. Those are the claims that would need independent verification before you build a team workflow on them.

## Licence, maintenance and what an upgrade costs you

Zellij is MIT licensed, stated in the README and in the LICENSE.md file at the repository root. MIT is permissive: you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and permission notice are preserved. That is a summary of the licence text, not legal advice, and if you are redistributing Zellij inside a product you should read LICENSE.md and the licences of its dependencies yourself.

Maintenance is visible from the outside. The repository is not archived, and the last push was on 2026-08-28. Releases are frequent: v0.44.3 on 2026-05-13, then v0.45.0 on 2026-08-20 and v0.45.1 on 2026-08-28. The project is on a 0.x version line, which in practice means minor releases can carry breaking changes. There is a CHANGELOG.md at the root, and that is where you should look before upgrading rather than assuming compatibility.

The upgrade cost has three parts. First, the binary itself, which for cargo users means re-running the install command. Second, your KDL configuration, which may need edits if keys or layout semantics change between minor versions. Third, any plugins you use, including the default ones, which ship with the binary and are versioned with it. The README's warning about cache corruption from main-branch builds is the strongest argument for staying on tagged releases: the failure mode is not a clean rollback.

Development is funded in part by sponsors, with G Research named in the README and a funding.json at the repository root. The project also has GOVERNANCE.md and CODE_OF_CONDUCT.md, so the contribution process is documented rather than implicit.

## Conclusion

Zellij is worth adopting if you want panes, tabs and a visible keybinding hint bar without writing a config first, and if you are willing to learn KDL for layouts and theming. It is the wrong tool if you already have a heavily tuned tmux.conf, if you need a supported Windows install path, or if you expect a stable plugin API across releases. Before committing, install v0.45.1 rather than building from main, confirm your OS has a package in docs/THIRD_PARTY_INSTALL.md, and read the layouts and configuration pages at zellij.dev because the README delegates both to the website.

## FAQ

### Is Zellij better than tmux?

The README does not make a comparative claim. It describes Zellij's philosophy as not sacrificing simplicity for power, and its differentiators as layouts, floating and stacked panes, a WebAssembly plugin system, multiplayer collaboration and a built-in web client. Whether that beats tmux depends on whether you want a status bar and a layout file out of the box or prefer tmux's scripting model.

### What does Zellij mean?

The README explains that Zellij is a style of mosaic tilework made from individually hand-chiseled tile pieces, used in Islamic geometric motifs in Morocco, Algeria, Tunisia and al-Andalus. The name is Arabic, romanized as zillij or zellige.

### How do I use Zellij on Windows?

The README does not document a Windows installation path. It recommends an OS package from docs/THIRD_PARTY_INSTALL.md, a prebuilt binary from the latest release, or cargo install --locked zellij. The repository contains a wix directory and a Windows-only embed-resource build dependency, but the README does not describe an end-user Windows install or mention WSL.

### How do I install Zellij?

The README's preferred route is a package for your OS, listed in docs/THIRD_PARTY_INSTALL.md. Otherwise you can download a prebuilt binary from the latest release and put it in $PATH, or compile it with cargo install --locked zellij. The README also offers a launch script at https://zellij.dev/launch for trying it without installing.

## Sources

- [Official documentation](https://zellij.dev)
- [Official README](https://github.com/zellij-org/zellij#readme)
- [Project repository](https://github.com/zellij-org/zellij)
- [Release notes](https://github.com/zellij-org/zellij/releases)

---

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