# Raspotify: a Debian package that turns a headless Linux box into a Spotify Connect endpoint > Raspotify wraps librespot as a systemd daemon and ships it as a .deb for Debian Stable. It is a thin packaging layer, which is both its appeal and the limit of what it can do for you. **dtcooper/raspotify** — A Spotify Connect client that mostly Just Works™ - Repository: https://github.com/dtcooper/raspotify - Website: https://dtcooper.github.io/raspotify - Stars: 5,216 · Forks: 234 - Language: Shell - License: MIT - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/dtcooper-raspotify ## What Raspotify actually is: a packaging layer, not a player Raspotify is a Debian package and an associated apt repository. The README describes it as thinly wrapping the librespot library as a systemd daemon. That sentence is the whole architecture. The audio work, the Spotify protocol handling and the Connect discovery are librespot's; Raspotify's job is to cross-compile librespot for a set of architectures, drop the binary into a package, and register a unit that starts at boot. That framing tells you who it is for. The README states plainly that Raspotify is intended for a headless environment. If you have a monitor and a desktop session, the README points at spotifyd instead, and for a turnkey Raspberry Pi audio distribution it points at moOde audio player. Raspotify assumes you never see the machine it runs on. You control it from the Spotify app on a phone or desktop, and you administer it over SSH. The licence is MIT, and the README carries a separate warning that Raspotify and librespot are for personal private use. It asks users not to run either in a commercial or public presentation, calling that a violation of Spotify's terms of service that could get all Raspotify and librespot users blocked. That is a usage boundary, not a technical one, and it sits outside the MIT grant. ## How the build works: Docker cross-compilation and a pinned librespot submodule The repository is a Shell project built inside Docker. The Dockerfile starts from rust:bookworm, adds the arm64 and armhf architectures to dpkg, installs crossbuild-essential for both plus the matching libasound2-dev, libpulse-dev and libssl-dev for each architecture, and adds the aarch64 and armv7 Rust targets. It installs cargo-deb and bindgen-cli into the image. The comment in the Dockerfile explains that PKG_CONFIG_PATH is deliberately not set at image level, because one architecture's directory would then be searched first for all of them; build.sh sets it per architecture alongside BUILD_TARGET. That is the kind of detail that only matters when a cross build silently links the wrong library, and it is documented. The Makefile drives everything. Each architecture target depends on a builder target that builds the Docker image, then runs the container with the repository mounted at /mnt/raspotify and ARCHITECTURE set to armhf, arm64, amd64 or riscv64. riscv64 is the exception: it uses a separate Dockerfile.riscv64 and a separate image tag, so you must run make builder_riscv64 before make riscv64. The default goal is all, which builds the four architectures in sequence. The librespot source is a git submodule. The README states that the librespot commit hash in the package filename comes from whatever commit is checked out in librespot/ at build time, and that build.sh runs git submodule update librespot, which resets the submodule to the commit recorded in the repository. So a plain build always produces the pinned revision, and moving to a different librespot revision means committing a new submodule pointer rather than passing a flag. ## Installing Raspotify and getting a first connection The README opens its installation section with a warning: there are guides floating around online, most of them outdated or wrong, and it says not to follow them. The supported path is the install script, which needs curl present first. ```bash sudo apt-get -y install curl && curl -sL https://dtcooper.github.io/raspotify/install.sh | sh ``` That command installs curl if it is missing, fetches the install script over HTTPS and pipes it to sh. The script adds the Raspotify apt repository and installs the package for the machine's architecture. If you would rather not pipe a remote script into a shell, the README offers four .deb files for direct download: raspotify-latest_armhf.deb, raspotify-latest_arm64.deb, raspotify-latest_amd64.deb and raspotify-latest_riscv64.deb, all served from the same host. Installing one of those manually is the alternative the project itself documents. After installation there is no command to run in order to start playback. The package installs a systemd daemon, so the service starts at boot, and the device appears in the Spotify app's Connect device list. Configuration is not documented in the README. It points to the wiki, and specifically to the Basic Setup Guide as the place to start. That means the answer to "where is the config file" is not in the repository README, and any value you set should be checked against the wiki rather than against a blog post. If you are building from source instead of installing, the sequence is to initialize the submodules and then invoke one architecture target. The README gives this example. ```bash git submodule update --init --recursive make arm64 # or: armhf, amd64, riscv64, all ``` The resulting packages land in the repository root, named raspotify__arm64.deb and asound-conf-wizard__arm64.deb. The second package is worth noticing: it is an ALSA configuration wizard shipped alongside the daemon, which suggests the project expects audio routing to be the part that goes wrong. The README does not document what the wizard asks or how it writes its configuration. ## Hardware it will not run on, and the Premium requirement Two constraints are stated without hedging. The README says that librespot, and therefore Raspotify, requires a premium account. There is no free-tier path, and the search results around this are answered the same way: without Premium there is no playback. The second is architecture. Raspotify does not support ARMv6 Pi boards, which the README identifies as the Pi v1 and Pi Zero v1.x, and links to a wiki page explaining the situation. The published packages cover armhf, arm64, amd64 and riscv64, so an ARMv6 board is outside the set rather than merely untested. The README also qualifies its Debian support. It targets Debian Stable, currently Debian 13 Trixie, and other Debian Stable based or compatible systems, with the parenthetical "your mileage may vary" attached to that second group. Raspbian and Raspberry Pi OS are named in the repository topics, but the compatibility claim in the README is deliberately loose. If you are on a derivative that has diverged from Debian Stable, the package may install and still misbehave, and the README has not promised otherwise. The disclaimer goes further than licensing. It repeats librespot's own statement that connecting to Spotify's API is probably forbidden by Spotify, notes that the project has not received word about that, and says to use it at your own risk. For a personal speaker in a living room that is a theoretical concern. For anything with an audience, the README's language is direct: it calls commercial or public use a flagrant violation of the terms of service and warns it could lead to all Raspotify and librespot users being blocked. ## spotifyd, moOde and the choice the README makes for you The README does not pretend Raspotify is the only answer, and the two alternatives it names are different in kind. spotifyd is the one to look at if you are on a desktop OS. It offers similar functionality, meaning it is also a Spotify Connect client, but it is not packaged as a Debian daemon for headless machines, so it does not make the same assumption that no one is sitting in front of the device. If your machine has a graphical session and a sound server tied to a user session, spotifyd fits that shape better than a system daemon does. moOde audio player is the other recommendation, and it is a different category entirely. The README calls it a turnkey audio solution for Raspberry Pi with Spotify Connect support. Raspotify gives you a daemon and expects you to handle the rest of the audio stack; moOde is a whole distribution with a web interface. If you want to configure playback from a browser and never touch a terminal, moOde is the project's own suggestion, and choosing Raspotify means accepting the terminal. The third comparison people look for is Raspotify against librespot itself, and the honest answer is that they are not alternatives. Raspotify packages a slightly modified librespot. Installing librespot directly means you own the build, the systemd unit and the upgrade path; installing Raspotify means the project owns those for you and you inherit its pinned submodule. The trade is convenience for control, and the build section above shows exactly how much control you give up: the librespot revision is fixed by the repository until you bump the submodule pointer yourself. ## Upgrades, maintenance and what the packaging costs you The last push to the repository was on 2026-09-21, and the most recent release is 0.48.2 from 2026-07-18, following 0.48.1 in 2025-11-24 and 0.48.0 in 2025-11-12. The project is not archived. The README notes that the original author, David Cooper, has left software engineering, and that Kim Tore Jensen has stepped up and is maintaining the project, with thanks also to a former maintainer. A named maintainer with releases in the current year is the relevant signal here, not any count of anything. The upgrade path depends on how you installed. If you used the install script and the apt repository, the package manager handles updates, and the README's related searches around updating reflect that. If you downloaded a .deb by hand, you are the upgrade mechanism. If you built from source, upgrading librespot means checking out a commit in the submodule, committing the pointer, and rebuilding, which the README documents as the recommended approach when you intend to keep that revision. The cost of the packaging layer is that your librespot version is whatever the maintainer pinned. A fix that lands upstream in librespot does not reach your device until a new Raspotify release picks it up, or until you build your own package against a newer commit. That is normal for a distribution package, and it is the reason the README bothers to document the submodule bump procedure at all. On licensing, the repository is MIT, which is permissive and carries no copyleft obligation on your own code. The README does not discuss the licences of librespot or of the audio libraries the Dockerfile links against, and it does not give guidance on redistribution of built packages beyond pointing at the LICENSE file. If you plan to redistribute a modified .deb rather than use it privately, read those upstream licences yourself; nothing in this repository settles that question for you. ## Conclusion Adopt Raspotify if you have a headless Debian Stable box, a Premium account, and you want a Spotify Connect target that installs from one shell command and is managed by systemd. Do not adopt it for a desktop, for ARMv6 hardware such as the Pi v1 or Pi Zero v1.x, or for any commercial or public playback, which the README says violates Spotify's terms of service. Before you commit, verify your board's architecture against the four published .deb packages and confirm that your audio stack is the one the wiki's Basic Setup Guide expects. ## FAQ ### Can I use Raspotify without Spotify Premium? No. The README states that librespot, and therefore Raspotify, requires a premium account. ### Can I use my Raspberry Pi as a Spotify player with Raspotify? Yes, provided the board is not an ARMv6 model. The README says Raspotify does not support the Pi v1 and Pi Zero v1.x, and the published packages cover armhf, arm64, amd64 and riscv64. ### How do I install Raspotify? The README gives one supported command: install curl with apt-get and pipe the install script from https://dtcooper.github.io/raspotify/install.sh into sh. It also offers four .deb packages for manual installation, and warns that most guides found online are outdated or incorrect. ### How do I set up and configure Raspotify? The README does not document configuration itself. It points to the project wiki, and names the Basic Setup Guide as a good place to start. ### What is the difference between Raspotify and librespot? Raspotify packages a slightly modified librespot as a Debian package and systemd daemon. The README describes it as thinly wrapping the librespot library, so librespot is the underlying player and Raspotify is the packaging and service layer around it. ### What is the difference between Raspotify and moOde? The README recommends moOde audio player as a turnkey audio solution for Raspberry Pi with Spotify Connect support, while Raspotify is a headless daemon you configure yourself. Choosing Raspotify means managing the audio stack rather than using a ready-made distribution. ## Sources - [dtcooper/raspotify on GitHub](https://github.com/dtcooper/raspotify) - [License: MIT](https://github.com/dtcooper/raspotify/blob/master/LICENSE) - [Project website](https://dtcooper.github.io/raspotify) - [README](https://github.com/dtcooper/raspotify/blob/master/README.md) - [Releases](https://github.com/dtcooper/raspotify/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dtcooper-raspotify