# librespot: a Rust Spotify Connect receiver you build yourself > librespot is an open source Spotify client library in Rust that turns a machine into a Spotify Connect receiver. It requires Premium, ships as a crate and as distro packages, and leaves the documentation to the wiki and the source. **librespot-org/librespot** — Open Source Spotify client library - Repository: https://github.com/librespot-org/librespot - Stars: 7,195 · Forks: 898 - Language: Rust - License: MIT - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/librespot-org-librespot ## What librespot replaces, and who actually needs it librespot is an open source client library for Spotify. It lets an application talk to Spotify's service, play music through a choice of audio backends, and register itself on the network as a Spotify Connect receiver. The README frames it as the alternative to libspotify, the closed-source library that Spotify deprecated, and notes that librespot also aims at features the official library never had. The audience is narrower than the description suggests. The README states that librespot only works with Spotify Premium and that this will remain the case, explicitly ruling out support for free-account behaviour such as limited skips and adverts. So the target user is someone with a Premium subscription who wants a speaker endpoint they control: a headless box in a rack, a Raspberry Pi behind a stereo, or a container on a home server. If you want a desktop music player with a window, this is not that. librespot is a library and a headless receiver binary, and the sample program in the repository is exactly that, a headless Spotify Connect receiver. ## The crate layout tells you where the seams are The repository is a Cargo workspace, and the top-level directories map closely to the pipeline: core, oauth, protocol, playback, audio, connect, discovery, metadata, cache. That split is the clearest architecture documentation the project offers, because the README says documentation is a work in progress and points readers at the code. The flow implied by those crates runs roughly like this. Authentication and token handling live in oauth. Session and transport concerns live in core. Spotify's wire protocol lives in protocol. Playback logic sits in playback, decoded audio goes through audio into one of the selectable backends, and connect handles the Spotify Connect side, which is what makes the process visible in the Spotify app as a device. discovery handles advertising that device on the local network. Compile-time feature flags bind these together: the default feature set is native-tls, rodio-backend and with-libmdns, and the Cargo.toml comments describe TLS backends as mutually exclusive with validation living in the oauth crate because it compiles first in the dependency tree. That last detail is worth pausing on. Putting feature validation in the crate that compiles first is a pragmatic trick, but it means a misconfigured build fails with an error attributed to oauth rather than to the feature you actually changed. Expect to read the message twice. ## Installing librespot from crates.io or from a package The README gives the shortest path first: librespot is published on crates.io as the librespot package, and cargo install librespot installs it. You need a Rust toolchain; the workspace manifest sets rust-version to 1.85 and edition to 2024, so an older toolchain will refuse the build. ```bash cargo install librespot ``` After that, the README's quick start runs the binary with a name and a bitrate. The -n flag sets the device name that appears in the Spotify app, and -b sets the audio bitrate in kbps. ```bash librespot -n "Librespot Speaker" -b 160 ``` If you build from source instead, the README lists the extra Linux dependencies. On Debian and Ubuntu the command is sudo apt-get install build-essential libasound2-dev, and on Fedora it is sudo dnf install alsa-lib-devel make gcc. macOS and Windows are described as needing nothing beyond a clone, because the default Rodio backend handles playback there. Then cargo build --release produces the binary, and the sample receiver is started from the target directory. ```bash target/release/librespot --name DEVICENAME ``` The README also shows a fuller invocation that exercises the options most people end up wanting: a custom name, 320 kbps, a cache directory, volume normalisation, an initial volume, and a device type that changes how the client is presented in the Spotify app. ```bash target/release/librespot -n "Librespot" -b 320 -c ./cache --enable-volume-normalisation --initial-volume 75 --device-type avr ``` When it starts correctly, the device appears in the Spotify app under the Connect picker and you can send playback to it. The README notes that the cache directory holds both audio data and credentials, and recommends permissions of 700 on it. Do that before the first run, not after. ## Where librespot breaks, and when it is the wrong tool The most concrete limitation is the account requirement. No Premium, no librespot. That is a product decision stated in the README, not a bug someone will fix. Audio output is the second place things go wrong. The default backend is Rodio, and the README says macOS and Windows build without extra dependencies because of it. On Linux the default path goes through system audio libraries, which is why libasound2-dev or alsa-lib-devel is needed at build time. If you are building on a headless server with no sound card, or inside a slim container without those development headers, the default build is the wrong starting point. The README points to COMPILING.md and the wiki for selecting other TLS, audio and discovery backends, and lists the options: Rodio, ALSA, GStreamer, PortAudio, PulseAudio, JACK, JACK over Rodio, SDL, Pipe and Subprocess. Pipe and Subprocess exist precisely because not every deployment has a sound device; the choice is yours to make at compile time, and it is not something you can flip at runtime. Documentation is the third limitation, and it is the one that will cost you time. The README says documentation is currently a work in progress and that the best way to learn how librespot works is to read the code and ask in the Gitter room. The options list lives on the wiki rather than in the repository, so the flags you can pass are not fully enumerated in the README. If you need a stable, documented API surface with a versioning promise, this project is not that. Finally, the README carries a disclaimer: using this code to connect to Spotify's API is probably forbidden by them, and you use it at your own risk. That is the maintainers' own wording, and it is the honest framing of the legal position. ## librespot vs spotifyd, raspotify and go-librespot The most common comparison is with spotifyd, and the difference is architectural rather than cosmetic. spotifyd is a daemon: you install it, it runs as a service, and it is built to be a Spotify Connect receiver and nothing else. librespot is a library with a sample receiver binary attached. If your goal is a speaker that starts at boot and stays out of the way, spotifyd's shape fits that goal more directly. If your goal is to embed Spotify playback inside your own Rust program, librespot is the thing you add as a dependency, and the examples directory shows the shape of that: get_creds.rs, get_token.rs, play.rs, play_connect.rs and playlist_tracks.rs each demonstrate a different entry point into the library. raspotify sits at a different level again. It is a packaging effort aimed at Raspberry Pi users, wrapping a receiver into something you install on a Pi and forget about. The trade-off is the same one you make with any distribution: less control over the build, fewer decisions about backends and TLS, in exchange for not having to make those decisions. go-librespot is the same idea as librespot implemented in Go rather than Rust. The practical consequence is the toolchain and the deployment story: a Go binary is a single static artifact, while a Rust build here is shaped by which TLS, audio and discovery features you enable. If you already run Go infrastructure and want one binary to copy around, that difference matters more than any protocol detail. ## Maintenance, upgrades and what the MIT licence leaves you The repository is not archived, and the last push to the dev branch was on 2026-09-11. Releases are tagged: v0.7.0 on 2025-08-24, v0.7.1 on 2025-08-31, and v0.8.0 on 2025-11-10. The Cargo.toml version matches 0.8.0, so the manifest and the release tags are in step. The upgrade cost is dominated by the compile-time feature model rather than by API churn. Because TLS backends are mutually exclusive and validated in the oauth crate, changing your TLS choice is a build configuration change, not a runtime flag. Moving between releases can therefore mean revisiting your build invocation, and the repository keeps a CHANGELOG.md at the top level for that purpose. The project also ships a rust-toolchain.toml, so a source checkout pins the toolchain for you, though a cargo install against your own toolchain will not. On licensing: everything in the repository is MIT. That is permissive, and it is the same licence the Cargo.toml declares for the workspace. It says nothing about Spotify's terms of service, which is a separate question the README's disclaimer already gestures at. The MIT grant covers the code the maintainers wrote; it does not grant you rights to Spotify's service, and it does not resolve the account requirement. If you plan to ship librespot inside a commercial product, the licence question and the service question are two different conversations, and only the first one is answered here. ## Conclusion Adopt librespot if you run a Spotify Premium account and want a headless Connect receiver on a Linux box, a Raspberry Pi or a server, and you are comfortable building Rust or installing a distro package. Do not adopt it if you use a free Spotify account, since the README states plainly that librespot only works with Premium and that this will remain the case, or if you want a supported product with a warranty. Before committing, verify three things: that your audio backend is in the list (Rodio is the default, with ALSA, GStreamer, PortAudio, PulseAudio, JACK, SDL, Pipe and Subprocess as alternatives), that your Rust toolchain meets the 1.85 minimum in the workspace manifest, and that you have a plan for the cache directory, because the README notes that an authentication blob is stored there and recommends permissions of 700. The last push to the dev branch was on 2026-09-11, so the code is moving, but the README still calls the documentation a work in progress. ## FAQ ### What is librespot? It is an open source client library for Spotify written in Rust. It lets applications play music through various audio backends and act as a Spotify Connect receiver, and the README describes it as an alternative to the deprecated closed-source libspotify. ### How do I install librespot? The README gives cargo install librespot as the shortest path, since the project is published on crates.io as the librespot package. It is also available through official package systems on several operating systems, and Repology lists the packaged versions. ### Can I use Spotify Connect on Linux with librespot? Yes. librespot acts as a Spotify Connect receiver, and the README's sample program is a headless receiver. On Linux you need extra build dependencies, such as libasound2-dev on Debian and Ubuntu or alsa-lib-devel on Fedora, because the default audio backend goes through system audio libraries. ### Is librespot safe? The README notes that when the cache feature is used, an authentication blob is stored for your account in the cache directory, and it recommends setting directory permissions on that cache directory to 700. The README also carries a disclaimer that using the code to connect to Spotify's API is probably forbidden by them and is done at your own risk. ### What is the difference between librespot and spotifyd? spotifyd is a daemon built to be a Spotify Connect receiver, while librespot is a client library that also ships a sample headless receiver binary. If you want to embed Spotify playback in your own Rust program, the examples directory shows entry points such as play.rs and play_connect.rs. ## Sources - [Issues](https://github.com/librespot-org/librespot/issues) - [librespot-org/librespot on GitHub](https://github.com/librespot-org/librespot) - [License: MIT](https://github.com/librespot-org/librespot/blob/dev/LICENSE) - [README](https://github.com/librespot-org/librespot/blob/dev/README.md) - [Releases](https://github.com/librespot-org/librespot/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/librespot-org-librespot