# Ironbar: a configurable GTK4 desktop bar for Wayland

> Ironbar is a Rust-based GTK4 bar for Wayland compositors, aimed at users who want more desktop-panel features than a minimal status bar without building an entire shell configuration. It supports Sway and Hyprland, partial Niri support, popups, scripts, custom widgets, multiple config formats, and multiple monitor-specific bars.

**JakeStanger/ironbar** — Customisable Wayland GTK4 bar written in Rust.

- Repository: https://github.com/JakeStanger/ironbar
- Website: https://crates.io/crates/ironbar
- Stars: 1,492 · Forks: 125
- Language: Rust
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/jakestanger-ironbar

## Why Ironbar targets a panel between minimal bars and full shells

Ironbar addresses a specific gap: a Wayland desktop bar with the convenience of built-in modules, but without requiring the user to assemble the complete surrounding interface from scratch. The project is written in Rust and uses GTK4 with Wayland layer-shell integration. Its intended users are people running compositors such as Sway and Hyprland, as well as some Niri users, who want a bar that can appear on one monitor or differ between monitors.

The design explicitly avoids choosing between two very different approaches. Compared with a lightweight status bar, Ironbar offers popup interfaces, tray integration, music and network modules, scripts, custom widgets, and richer styling. Compared with a full custom shell solution, it provides a standardized configuration model and modules that should behave consistently without requiring every compositor integration to be rebuilt for each display. That middle position is useful for a desktop configuration that needs several pieces of panel information but does not need a complete shell replacement.

The repository also makes a reliability claim about its asynchronous design. Scripts are intended to run in the background, so one module or service that blocks or crashes should not stop the rest of the bar. The README describes this as a multithreaded async design, although it does not document detailed retry policies, failure reporting, or recovery behavior for every external service.

## Ironbar's GTK4, compositor, and module architecture

The visible architecture is a configurable GTK4 bar rather than a shell binary that owns the whole desktop. The package description identifies GTK Layer Shell and Wayland, while the repository topics include wlroots, Sway, Hyprland, Niri, and gtk4. The README lists first-class support for Sway and Hyprland, with partial support for Niri. That distinction matters when choosing a configuration: Niri is not documented here as having the same coverage as the two primary compositors.

Configuration is the central data flow. A single configuration can define one bar across all monitors or multiple unique bars assigned to different monitors. The package's default feature set enables modules for battery, Bluetooth, brightness, clipboard, clock, launcher, menu, music, network management, notifications, scripts, system information, tray, volume, and workspaces. It also enables bind mode support, custom widgets, HTTP, CLI and IPC support, and all four listed configuration formats: JSON, YAML, TOML, and Corn.

The module system is compiled through Cargo features. This means an installed package may expose only the features selected by its build, while a source build can choose the default feature set or a narrower set. The README also documents popups and dynamic content, including Lua, and says that CSS is hot-loaded. Configuration hot-reloading is documented as well. These mechanisms suggest a bar assembled from module instances and styled outside the module configuration, rather than a fixed status-bar template.

## Installing Ironbar on Linux distributions and with Cargo

The README offers package-manager, Cargo, and source installation paths. For distributions with an existing package, use the package manager command documented for that distribution. Ironbar is a desktop GUI application, so the runtime and build dependencies remain relevant even when a binary is already packaged. The README recommends a Nerd Font for displaying symbols.

On Arch Linux, the documented commands install either the official `ironbar` package or the AUR git package. The first command uses the official package, while the second tracks the Git version through `yay`.

```bash
pacman -S ironbar
# or
yay -S ironbar-git
```

For Nix users, the README provides a `nix-shell` invocation. The command opens the package in a Nix shell rather than describing a permanent system installation.

```bash
nix-shell -p ironbar
```

Void Linux has its own documented package command.

```bash
xbps-install ironbar
```

For a prebuilt binary through `cargo-binstall`, install `cargo-binstall` and the documented runtime dependencies first, then run:

```bash
cargo binstall ironbar --locked
```

This path installs a prebuilt binary from GitHub according to the README. It is different from the source-build path below.

## Building the current Ironbar source with Cargo

The source instructions begin by cloning the repository and changing into its directory. The build command uses the release profile, producing the executable at `target/release/ironbar`. The README then points to the `install` command as the final copy operation, but its example does not provide a complete destination path, so the installer must choose the path appropriate for the system.

```bash
git clone https://github.com/JakeStanger/ironbar.git
cd ironbar
cargo build --release
```

The build dependencies are not reproduced in the README excerpt. It directs users to the project wiki's build requirements page. The repository includes a `Dockerfile`, a `flake.nix`, `default.nix`, and a `shell.nix`, which indicates that Nix and container-based development environments are part of the repository layout. The Dockerfile copies the Rust toolchain and runs the repository's Ubuntu setup script, but it does not by itself show how to launch a completed bar.

The source build is preferable when a user needs to inspect the feature set, build from the current default branch, or use the repository's development files. The package-manager route is simpler when the distribution already carries a compatible build. `Cargo.toml` identifies the current package version as `0.20.0-pre`, while the README points to released versions through the crates.io and release pages. A source checkout can therefore differ from the latest documented release, which is worth checking before upgrading.

## A first Ironbar configuration with one bar, CSS, and module placement

The README's Home Manager example is the only concrete configuration shown. It creates a flake input for Ironbar, enables the Home Manager module, defines a monitor named `DP-1`, places the bar at the top, sets its height to 16, starts it with a clock module, and ends it with a tray module. The example also includes CSS and exposes `features` for selecting build features.

The configuration fragment below is extracted from that example and is shown as TOML-style Nix syntax inside a Nix expression. It illustrates the relationship between monitor identity, placement, module order, and styling rather than presenting a complete standalone configuration.

```toml
monitors = {
  DP-1 = {
    anchor_to_edges = true;
    position = "top";
    height = 16;
    start = [
      { type = "clock"; }
    ];
    end = [
      { type = "tray"; icon_size = 16; }
    ];
  };
}
```

The CSS in the same example selects `Noto Sans Nerd Font`, sets a 16px font size, removes borders, and sets the border radius to zero.

```css
* {
  font-family: Noto Sans Nerd Font, sans-serif;
  font-size: 16px;
  border: none;
  border-radius: 0;
}
```

The README does not give a short command for starting Ironbar after these settings are written. It links to the configuration guide and styling guide for that step, so the concrete launch command is not documented in the README excerpt. Readers using Home Manager should follow the full example's module structure and place these values under `programs.ironbar.config` and `programs.ironbar.style` as shown in the repository example.

## Where Ironbar's feature breadth creates operational trade-offs

Ironbar's broad default feature set is its main convenience and its main packaging consideration. The default includes many native desktop integrations, so a standard build pulls in modules that a particular user may never display. A package maintainer can control this through Cargo features, but the README does not document a concise minimal-feature recipe or explain which optional dependencies are required for each external service.

The async design also does not remove integration dependencies. Battery, Bluetooth, brightness, clipboard, network management, notifications, tray, volume, music, workspaces, and system information depend on desktop libraries or the surrounding compositor environment. The README names these modules but does not provide failure matrices for missing daemons, unavailable hardware, compositor-specific APIs, or service outages. A bar that continues running when one service blocks is useful, but it does not imply that every module has equivalent support on every compositor.

Hot-reloaded CSS and configuration reduce iteration time, yet they also make configuration syntax important. JSON, YAML, TOML, and Corn are available, but the README does not say whether changing the configuration can restart modules, which fields are reloaded, or how syntax errors are surfaced. Those details should be checked in the configuration guide before using the feature in a production desktop session.

## Ironbar compared with a compositor-native bar or a custom shell panel

The practical alternative is a compositor-native or shell-provided bar. 

Ironbar takes a different approach. It centralizes a broad set of desktop integrations under one Rust application and a common module configuration, with support for modules that are not tied to a single compositor's minimal bar model. Its popup system, scripts, Lua support, custom widgets, and multiple layout types are the distinguishing features relative to a basic status bar. The trade-off is that the user accepts Ironbar's GTK4, layer-shell, module, and configuration model instead of using only compositor-native behavior.

For a minimal desktop, the native compositor bar may have fewer moving parts. For a user who wants a shared panel with music controls, tray behavior, notifications, scripts, and popup content, Ironbar offers a more direct configuration target. The repository's first-class Sway and Hyprland support is the relevant decision point, with Niri support explicitly described as partial.

## Ironbar maintenance, releases, and MIT licensing

The repository is not archived, and the last push was on 2026-10-14. The recent releases listed are `v0.19.1` on 2026-09-20, `v0.19.0` on 2026-05-17, and `v0.18.0`, the GTK4 release, on 2025-12-17. The repository layout includes `CHANGELOG.md`, `CONTRIBUTING.md`, `Cargo.lock`, CI configuration, release workflows, multiple package definitions, and a service unit. Those files indicate that release and packaging work are represented in the project, although the README does not state a support policy or a guaranteed upgrade path.

Upgrading through a package manager can be simpler because the distribution controls build dependencies and feature selection. Cargo installation introduces its own concern: `cargo install ironbar --locked` is tied to the crate version selected by Cargo, while the source checkout is tied to the current branch. The repository's `Cargo.toml` labels itself `0.20.0-pre`, so users should distinguish a prerelease source state from a released crate when interpreting version output.

The package is licensed under MIT. That means the repository identifies an MIT license rather than a proprietary distribution model. The license file is the appropriate source for the exact permissions and conditions; this review does not interpret its legal meaning.

## Conclusion

Ironbar fits Wayland users who want a configurable panel with a conventional module system, especially on Sway and Hyprland. It is less suitable for users who need a minimal bar with very little UI machinery or require the same documented feature depth on Niri. Before adopting it, verify your compositor, the required GTK4 runtime dependencies, the configuration formats you intend to use, and whether the modules you need are enabled by the selected installation package. The clearest first adoption boundary is whether Ironbar's GTK4 and compositor requirements fit your current desktop setup.

## FAQ

### How do I install Ironbar on Linux?

The README documents package-manager installation for Arch Linux, Nix, and Void Linux, as well as installation through `cargo-binstall` or Cargo. The Arch command is `pacman -S ironbar`, the Void command is `xbps-install ironbar`, and the Cargo command is `cargo install ironbar --locked`.

### Does Ironbar work with Sway and Hyprland?

The README lists first-class support for Sway and Hyprland. It describes Niri support as partial, so Niri users should verify the individual modules they need.

### What configuration formats does Ironbar support?

The README says Ironbar supports multiple configuration languages and hot-reloading. The default feature list enables `config+json`, `config+yaml`, `config+toml`, and `config+corn`.

## Sources

- [JakeStanger/ironbar on GitHub](https://github.com/JakeStanger/ironbar)
- [License: MIT](https://github.com/JakeStanger/ironbar/blob/master/LICENSE)
- [Project website](https://crates.io/crates/ironbar)
- [README](https://github.com/JakeStanger/ironbar/blob/master/README.md)
- [Releases](https://github.com/JakeStanger/ironbar/releases)

---

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