Spotube: a plugin-driven music client that keeps playback local

The problem Spotube actually addresses

Most streaming clients are thin interfaces over a company's servers. The catalogue, the recommendation engine and the audio delivery all sit behind one vendor, and the client is replaceable. Spotube inverts that. The README describes it as "A cross-platform extensible open-source music streaming platform" where you "Bring your own music metadata/playlist/audio-source with plugins created by community or by yourself." The client is the durable part; the sources are swappable.

That design targets a specific listener: someone who wants a desktop and mobile player with a consistent interface but does not want the catalogue tied to a single provider. It also targets developers, since the README frames plugin authorship as a first-class activity rather than an afterthought. Playback control is handled locally rather than on a server, which the README lists as a feature. The project is written in Dart and built with Flutter, so the same codebase covers Windows, macOS, Linux, Android and iOS.

How the plugin, extraction and playback layers fit together

The architecture splits into three concerns. Metadata and playlists come from a plugin. Audio comes from an extraction path. Playback happens in a local player.

The credits section names the concrete pieces. Piped and Invidious are described as alternative YouTube frontends; yt-dlp is "A feature-rich command-line audio/video downloader"; NewPipeExtractor is "NewPipe's core library for extracting data from streaming sites"; and YouTubeExplodeDart is a Dart port of the youtube_explode library that the README says "Supports several API functions without the need of Youtube API Key." MPV is the media player underneath, described as "a free (as in freedom) media player for the command line." MusicBrainz and ListenBrainz supply metadata and listening-data services, and LRCLib is "A public synced lyric API."

So the data flow is: a plugin resolves a track, an extractor obtains a stream, MPV plays it, and lyrics are fetched independently from LRCLib. That last point matters. The README claims "Time synced lyrics regardless of the plugin support," which is only possible because lyrics are not the plugin's responsibility. The dependency chain is long, and every link is a third party.

Installing Spotube and playing a first track

The README's installation table lists per-platform methods. On Debian and Ubuntu you download the .deb from the latest release and install it locally:

sudo apt install ./Spotube-linux-x86_64.deb

After that, launching Spotube from your application menu should open the player. Arch and Manjaro users have two package paths in the table:

sudo pamac install spotube-bin

or, with yay:

yay -Sy spotube-bin

Flatpak is also listed, with the application ID given as com.github.KRTirtho.Spotube:

flatpak install com.github.KRTirtho.Spotube

On macOS the README documents a Homebrew tap and cask:

brew tap krtirtho/apps
brew install --cask spotube

Windows has three package-manager options. Chocolatey uses `choco install spotube`. Scoop needs the extras bucket added first:

scoop bucket add extras
scoop install spotube

WinGet uses the identifier KRTirtho.Spotube:

winget install --id KRTirtho.Spotube

Android ships as an APK from the releases page or through F-Droid under the package oss.krtirtho.spotube. iOS is the awkward one: the README provides an iPA file and states it "Requires sideloading with AltStore or similar tools." There is no App Store listing in the table. Once installed, the first real use is the same everywhere: open the app, pick a plugin as the metadata and audio source, and play a track. The README does not walk through plugin selection, so expect to consult the plugin documentation separately.

Where Spotube breaks or is the wrong choice

The AppImage entry in the README's own table is a warning, not an install method. It reads: "AppImage's lacking stability led to it's temporary removal." A project removing a distribution format for stability reasons is telling you something about the packaging surface, and it is worth reading that line before assuming every listed format is equally reliable.

iOS is the second constraint. An iPA that requires AltStore or a comparable sideloading tool is not a normal install path, and sideloaded builds expire and need refreshing. If you want a music app you install once and forget, this is not it on that platform.

The third constraint is structural. Because audio is resolved through extractors and alternative frontends, playback depends on services Spotube does not control. When an upstream frontend changes its response format or blocks a client, tracks stop resolving until the extractor is updated. The README lists no fallback, no offline catalogue and no guarantee. If you need a player that works when a third-party service has a bad week, Spotube is the wrong tool. The README also does not document rollback or downgrade steps, so pinning a working version is something you work out yourself.

Spotube against a conventional streaming client

A conventional client such as Spotify's official app takes the opposite approach. The catalogue, the audio delivery and the client are one product from one vendor. You get a predictable library and a stable playback path, and in exchange you accept the vendor's catalogue decisions, its account requirements and its data collection.

Spotube's README makes the trade explicit: "No telemetry, diagnostics or user data collection," and "Playback control is done locally, not on the server." Those are real differences in approach, not marketing. But the same design that removes the vendor also removes the guarantee. Spotify's app does not stop working because a YouTube frontend changed shape; Spotube can.

The other difference is scope. Spotify's client is a product with a support organisation behind it. Spotube is maintained by a small named team listed in the README, with releases the README says "usually release every 3-4 months." That cadence is fine for a media player and slow for a security-sensitive tool. Choose based on which risk you would rather carry: a vendor that controls your library, or a client that depends on services you do not control.

Maintenance, releases and the BSD-4-Clause licence

The repository is not archived, and the last push was on 2026-06-05, which is the same date as the v5.1.2 release. Before that, v5.1.1 landed on 2026-02-24 and v5.1.0 on 2025-11-14. That spacing matches the README's own statement that new versions "usually release every 3-4 months," so the release rhythm is roughly what the project advertises. Nightly builds are published separately from the GitHub Releases page under the nightly tag, which gives you a faster channel if you want fixes before a stable cut, at the cost of running unreleased code.

Upgrade cost depends on platform. Package-manager installs (Flatpak, Homebrew, Chocolatey, Scoop, WinGet, pamac, yay) move with the package manager. Manual .deb and .rpm installs do not, so you re-download and reinstall. The Makefile shows the release pipeline generates checksums through scripts/gensums.sh, so published artifacts have a verification path, though the README does not explain how to use it.

The licence is BSD-4-Clause. The README links a post explaining the choice. BSD-4-Clause includes an advertising clause, which is unusual among modern permissive licences and can impose attribution requirements on redistributors that BSD-3-Clause does not. If you plan to redistribute Spotube or a build of it, read the LICENSE file rather than assuming it behaves like MIT. This is not legal advice; it is a pointer to the clause that most often surprises people.

Editorial conclusion

Spotube suits listeners who want a local, plugin-driven client and are willing to sideload on iOS or accept that audio resolution depends on third-party extraction services. It is the wrong tool if you need a guaranteed, always-available catalogue, since playback depends on Piped, Invidious, yt-dlp and NewPipeExtractor staying functional. Before committing, install the stable build for your platform, confirm playback on one track, and check whether the plugin you need is listed in the repository's plugin documentation, because the README does not enumerate them.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes