Hummingbird: a native Rust music player built on GPUI

A native app with no web component in it

Hummingbird is a modern music player written in Rust using GPUI, described as designed to be performant and lightweight while maximising extensibility and maintaining a high design standard. The first item in the feature list is the one that matters most architecturally: a fully native application with no web component.

That choice shows up in the dependencies. The Cargo manifest pulls in `gpui`, renamed from the package `gpui-unofficial`, along with `gpui_platform` with the wayland, x11 and font-kit features, and `cntp_i18n` with a gpui feature for translations. Using an unofficial fork of the editor toolkit is a statement about the project's maturity: GPUI is the framework Zed is built on, and rather than wait for a stable public crate, Hummingbird depends on the community build of it.

The rest of the dependency list is equally deliberate. `mimalloc` with the no-thp feature as the allocator, `cpal` with pipewire for audio output, `lofty` for audio metadata, `nucleo` for fuzzy search, `discord-rich-presence` for the Discord integration, `moka` as a cache, `notify` for filesystem watching, and `postcard` for serialisation.

The feature set is standard for a good local player: FLAC, MP3, OGG Vorbis, Opus, AAC and WAV playback, a SQLite-backed library, playlists, lyrics, fuzzy-find search, ReplayGain, scrobbling to Last.fm and ListenBrainz, a graphical parametric equalizer, desktop integration, theming with hot reload and Discord RPC.

Signing and shipping builds across three package systems

Official binaries are published for Windows, macOS and Linux as an AppImage, for 64-bit ARM and Intel architectures, and there are also a Fedora COPR and an Arch AUR package.

The Fedora route uses the `william341/hummingbird` COPR:

sudo dnf copr enable william341/hummingbird
sudo dnf install hummingbird

And Arch users install the `hummingbird-player` AUR package:

paru -S hummingbird-player

For NixOS there is a flake, and the documentation notes that work towards upstreaming Hummingbird into nixpkgs is currently ongoing.

Unstable builds are cut automatically by CI from the latest commit and uploaded to a `latest` release tag, which gives you a rolling option if the tagged release is behind. Official builds are signed with `minisign`, the signature is attached to the release and has to be downloaded separately and placed next to the binary you are verifying, and the check is a single command:

minisign -Vm <file> -P RWTVGbNhJ/77g9Dm280SNcfxaPz118Hgg8vI55tFX83sIMiObZuxpDyV

That workflow is worth a moment's attention. The signature is not in the same download as the binary, which is a deliberate pattern: if an attacker controlled the release page they could replace both together, so the key has to come from a source they do not control, in this case the repository itself. The cost is that verification is two downloads and a terminal command rather than a single click, and the benefit is that a compromised release page still does not give you a signed binary.

Building from source, and what the Cargo features reveal

The build instructions in the readme start from a clone and note the Linux development packages needed for xcb-common, x11, wayland, openssl and pulseaudio. Scrobbling credentials are environment variables, and the comment is clear that the project still builds without them, with scrobbling simply disabled:

git clone https://git.mailliw.org/hummingbird/hummingbird
cd hummingbird

# last.fm api keys must be set in the environment for scrobbling to work
# these can be obtained from https://www.last.fm/api/account/create
# you can also set these in a .env file in the root of the project
#
# Hummingbird will still build without these keys, but scrobbling will be disabled
export LASTFM_API_KEY="your key"
export LASTFM_API_SECRET="your secret"

# debug mode will result in noticable slowdown in some cases
cargo build --release

The Cargo features are the clearest statement of the project's direction:

[features]
console = ["dep:console-subscriber", "tokio/tracing"]
# Use the system allocator so Heaptrack can observe Rust allocations, and avoid loading PipeWire
# concurrently with the GPU driver during startup.
heap-profileable = []
update = ["dep:semver", "dep:minisign-verify", "dep:winreg", "online"]
online = ["dep:zed-reqwest"]
libre-services = ["online"]
proprietary-services = ["online"]
default = ["libre-services", "proprietary-services"]

The `update` feature pulls in minisign verification, a semver crate and a Windows registry crate, which is how the application checks for and installs updates. The `online`, `libre-services` and `proprietary-services` features gate the network code, so a build with those off does no network access at all. The `heap-profileable` feature swaps in the system allocator so that a profiler can observe allocations, with a comment about avoiding PipeWire loading concurrently with the GPU driver at startup, which tells you the author cares about startup cost.

The package version in the manifest is 0.4.0 while the newest tagged release is 0.3.0, so the source tree is already ahead of the released binary.

The extension and cloud story is planned, not shipped

The planned features list is the honest roadmap, and it is long.

The first item is WASM extension support, with four categories named: codecs, scrobble services, metadata services and cloud storage services. A WebAssembly plugin system is a serious architectural commitment for a Rust application, and the fact that it is planned rather than present tells you the current 0.x releases are not the version to design an extension ecosystem around.

The second item is improved library management: filtering, tags, more advanced playlist management, statistics and star rating. The third is cloud storage support, with Jellyfin, OpenSubsonic and WebDAV named. The list also includes full keyboard navigation and a sleep timer.

For a user, this list is the difference between a good local player and the thing you eventually want, which is a player that talks to the library you already have. None of the cloud options exist yet, so if your music lives in a Jellyfin or Navidrome instance, Hummingbird today is a client for local files only.

The repository layout supports the sense of a project with real structure under the hood: a `migrations` directory for the SQLite schema, a `queries` directory for the database layer, `res` for resources, `translations` for localisation, a `package` directory for packaging, a `flake.nix` with a `flake.lock`, a `rust-toolchain.toml` pinning the toolchain, and a `Contemporary.toml` file that looks like it drives a release process. There is also a `.parlance.json`, which is the translation catalogue format the `cntp_i18n` dependency expects.

A mirror, a forge, and where the project actually lives

One detail in the repository description changes how you should treat the links in the readme. The GitHub repository is labelled a mirror, and the canonical home is on a self-hosted Forgejo instance at git.mailliw.org, with the release page and the documentation there rather than on GitHub.

That has a few practical consequences. The `git clone` in the build instructions points at the forge, not at GitHub, and so do the release downloads. The repository contains a `.forgejo` directory, and CI configuration under `.woodpecker`, which is the Woodpecker CI fork that runs the pipelines and produces the `latest` build tag.

The project also keeps a `.github` directory and a `.cargo` directory, so GitHub remains useful for issues and for the crates.io-adjacent configuration, while the forge holds the source of truth.

For anyone tracking the project, the git history is the fastest way to see the state of things, and the mismatch between the 0.4.0 version in the manifest and the 0.3.0 release is a good place to start. The last push was on 2026-10-20, three days before this review, so the work is current, and the previous releases were 0.2.0 in March 2026 and 0.1.1 in December 2025, which is a slow but visible pace for a 0.x project.

The licence is Apache 2.0, with the `LICENSE` file at the root and the same declaration in the Cargo manifest.

Editorial conclusion

Hummingbird suits a Linux, macOS or Windows user who wants a local music library player with a native interface, scrobbling and ReplayGain, and who is willing to follow a project that is still at version 0.3.0. It is a poor fit for someone who needs cloud library sync today, since Jellyfin, OpenSubsonic and WebDAV are listed as planned rather than shipped, and a poor fit for anyone who needs plugins now, because the WASM extension system is also on the planned list. Before you install, verify the download with the published minisign key, and check the release notes for 0.3.0 because the Cargo manifest already says 0.4.0, which means the tagged binary and the source tree are at different points.

Frequently asked questions

Official sources

1. hummingbird-player/hummingbird on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases