Sonora: a Rust and GPUI client that plays Spotify, YouTube Music, Subsonic and local files

The problem Sonora picks: four catalogs, four windows

Most desktop music setups end up split across services. A Spotify account holds the playlists you have curated for years, YouTube Music holds the uploads and the live sets that never made it to streaming, a self-hosted Navidrome instance holds the files you actually own, and a folder on disk holds the rest. Each one has its own player, its own search box, its own queue, and its own idea of what a now-playing bar looks like.

Sonora's answer is to be one native window over all four. The README lists the providers directly: Spotify, YouTube Music, Subsonic/OpenSubsonic, and local playback. The audience is therefore not the person who wants a music library manager, and not the person who wants a server. It is the person who already has accounts and servers and wants a single client that speaks to all of them, written in Rust rather than shipped as an Electron bundle. The topics on the repository include spotify, streaming and youtube, which matches that framing.

The scope is deliberately wide on the client side: gapless playback, audio normalization, shuffle, sleep timer, synced and karaoke lyrics with romanization, scrobbling to LastFM, ListenBrainz, LibreFM and Maloja, Discord Rich Presence, theming and window styling. That is a lot of surface for one application, and the release cadence reflects it. Three tagged releases landed between 2026-09-12 and 2026-09-15, which suggests the project is moving quickly and that you should expect the interface to shift under you.

How the GPUI fork and the crate split shape the build

Sonora does not use upstream GPUI. The workspace Cargo.toml pins gpui and gpui_platform to a git revision in the sonorahq/gpui fork, with the font-kit, wayland and x11 features enabled for the platform crate. That single line explains most of the project's build cost: you are not compiling a published crate from crates.io, you are fetching a specific commit of a UI framework and building it alongside the application. The README's own note about the AUR source package says it "takes a while on a Rust and GPUI tree," which is an unusually candid description of what a from-source build involves.

The architecture is a workspace with one crate per concern. The members list in Cargo.toml names them: embed, i18n, icons, music, state, storage, input, router, ui, views, webview. Read that as a layered client. The music crate carries playback and provider logic, state and storage handle persistence, router and views handle navigation and screens, ui and icons handle presentation, i18n handles the translation tables the README publishes, and webview exists because some providers need an embedded browser surface rather than a plain HTTP call. The webview2-com dependency on the Windows side and the webview crate in the workspace point at that same need.

Audio output goes through cpal, and the workspace pulls in ksni for a Linux tray icon, discord-rich-presence for the Rich Presence integration, and kakasi plus deunicode for the lyrics romanization feature. None of this is visible to a user, but it tells you where the maintenance load sits: a forked UI framework, a cross-platform audio abstraction, and a webview layer are three separate things that can break on an OS update.

Installing Sonora and getting a first track playing

Installation is platform-specific and the README documents each path separately. On macOS the project ships a Homebrew cask from a third-party tap, and then asks you to strip the quarantine attribute, which is the standard workaround for an unsigned or unnotarized app.

brew install --cask nolight132/tap/sonora
xattr -dr com.apple.quarantine /Applications/Sonora.app

The xattr command is not optional in practice. Without it Gatekeeper will refuse the first launch, and the README's parenthetical "thanks Apple" makes clear the maintainers know it.

On Arch Linux there are two AUR packages with different trade-offs. sonora-bin installs the prebuilt release binary; sonora builds the same version from source against your own system libraries, which is slower but avoids linking against whatever the release build used.

yay -S sonora-bin

Whichever you pick, the README states that either pipewire-alsa or pulseaudio-alsa is required, matching your sound server. That is an ALSA bridge, and without it the application has no route to your audio device.

Flatpak is the least interactive option and the only one that updates itself through the normal mechanism.

flatpak install --user https://sonorahq.github.io/sonora/sonora.flatpakref

After that, flatpak update picks up new releases along with everything else. The AppImage path is the opposite: download the x86_64 or aarch64 artifact from the latest release, make it executable, run it, and remember that it will never update itself.

chmod +x sonora-*.AppImage
./sonora-*.AppImage

For Nix users the flake exposes three package outputs (default, sonora for a source build, and sonora-bin for a prebuilt binary if one exists for your platform), plus a Home Manager module under programs.sonora. The README's example sets the provider and the theme through that module.

{
  imports = [ inputs.sonora.homeManagerModules.default ];
  programs.sonora = {
    enable = true;
    settings = {
      provider = "youtube";
      appearance.theme = "dark";
    };
  };
}

The settings keys shown are provider and appearance.theme. The README does not enumerate the rest of the configuration schema, so treat the Home Manager module as documented by example rather than by reference. On Windows there is an installer, an ARM installer, and a portable windows-msvc.exe per architecture.

Once it runs, the first real task is signing in to a provider and playing something, since the README's feature list assumes at least one source is configured. The documentation does not walk through the sign-in flow or describe where credentials are stored; PRIVACY.md and the storage crate exist, but the README does not summarize either.

Where Sonora is the wrong tool

Sonora is a client. It does not host a library, it does not scan a music folder into a managed database in the way a player like foobar2000 or Strawberry does, and the README does not present it as a replacement for a server. If your goal is to organize, tag and own a collection, the Subsonic integration here is a client for a server you already run, not a server itself.

The AppImage is the weakest distribution channel and the README says so plainly. It carries no Vulkan driver and no ALSA bridge, both of which must come from your system, and it does not update itself. On a machine without a working Vulkan setup you will get a window that fails to render, and the documentation does not describe a fallback. That is a real failure mode, not a hypothetical one, and it is the reason the Flatpak and AUR paths exist.

The platform support line is also softer than it looks. macOS, Windows and Linux are listed as supported; FreeBSD is qualified with "(probably)". There is no CI evidence in the README for FreeBSD, and a Rust GUI stack that pins a Wayland and X11 feature set is not obviously portable to a BSD without work.

Finally, the release pace cuts both ways. Three releases in four days means fixes arrive fast, and it also means the application is not stable in the sense a long-term user might want. The README's own note that "everything is (or will be) customizable" is a promise about the future, not a description of the present.

Alternatives and the actual difference in approach

The closest comparison is a browser. Spotify's web player and YouTube Music's web player reach the same catalogs, require no install, and update themselves. The difference is architectural: a browser tab is sandboxed and cannot touch your filesystem, cannot scrobble to four services through a native integration, cannot show Discord Rich Presence with a local process, and cannot play a local file next to a streamed one. Sonora's value is exactly those things, and if you do not want any of them the browser wins on every other axis.

On the self-hosted side, the natural alternative is whatever desktop client your Subsonic server already recommends, or a native player pointed at a mounted library. Those tools generally do one thing: they talk to your server, or they play your files. Sonora's difference is that Subsonic is one provider among four in the same queue, so a Navidrome track and a Spotify track can sit in the same session. Whether that matters depends entirely on whether you actually mix sources, and many people do not.

There is also the framework question. Because Sonora pins a fork of GPUI, its rendering and input behaviour are tied to that fork's revision rather than to a stable upstream release. A project built on a mainstream toolkit inherits that toolkit's platform fixes for free; Sonora inherits them only when the fork rebases. That is a deliberate trade for control over the UI layer, and it is the kind of decision that looks fine until a compositor changes something.

Licence, upgrade cost and what the repository does not say

Sonora is GPL-3.0-or-later. The workspace Cargo.toml declares that as the workspace package licence, and the repository carries a COPYING file. For an end user this changes nothing: you can install and run it. For anyone embedding it, shipping it inside a product, or linking it into a proprietary application, the copyleft terms apply to the combined work, and the project's own THIRD-PARTY.md suggests the dependency set is large enough to be worth reading before you make assumptions. This is not legal advice; if the distinction matters to your organization, that is a question for counsel.

Upgrade cost varies by channel. Flatpak and the Home Manager module are the cheap paths, because updates arrive through the tool you already use. The AUR binary package tracks releases through your AUR helper. The AppImage is manual: you download a newer file over the old one. The macOS cask updates through Brew, but a re-install may reintroduce the quarantine attribute, so the xattr step is worth remembering.

The repository does not document a rollback procedure, a configuration file format outside the Nix module, or a migration path between versions. Given the release cadence, that gap matters more than it would for a slower project. There is also no published statement in the README about how provider credentials are stored or refreshed, only the existence of PRIVACY.md and a storage crate. If you are going to sign in to a paid account through this client, that is the first thing to read in the source.

Editorial conclusion

Adopt Sonora if you already pay for Spotify or YouTube Music and want a native window instead of a browser tab, or if you run Navidrome or another Subsonic server and want a desktop client that also reaches those services. Skip it if you need a library manager that owns your files, if you are on a platform where the only artifact is a self-updating-less AppImage, or if GPL-3.0-or-later is incompatible with how you ship software. Verify first that your distribution's audio bridge is present (pipewire-alsa or pulseaudio-alsa on Arch) and that the AppImage's missing Vulkan driver and ALSA bridge are already satisfied by your system, because Sonora does not bundle either.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. sonorahq/sonora on GitHub