Spooty

A self-hosted tool for building local music libraries from Spotify playlists, honestly reviewed. What it is, how it works, and what you’re getting into legally.

TL;DR

• What it is: A self-hosted web app that reads your Spotify playlists and albums, finds matching audio on YouTube, and downloads the files to your server in your chosen format [README].
• Who it’s for: People who want a permanent local music library from their Spotify playlists without manually hunting YouTube for every track. Works best for hobbyists comfortable with Docker and Spotify’s developer dashboard.
• Cost: $0 in software (MIT license). Requires a free Spotify developer app account for API credentials. A $5–10/mo VPS covers hosting if you don’t run it locally [README].
• Key strength: Playlist subscriptions — point it at a playlist or artist page and it will automatically pull new releases as they appear. Clean web UI, multiple output formats, Docker deployment in a single command.
• Key weakness: Small project (5 contributors, 1,146 stars). No third-party reviews. The setup requires creating a Spotify developer application, which is an unusual friction step for a self-hosted tool. The legality of downloading music you “own rights to” is ambiguous in practice.

---

What is Spooty

Spooty is a self-hosted web application that functions as a bridge between Spotify’s catalog metadata and YouTube’s audio. You paste a Spotify URL for a track, playlist, or album; Spooty calls the Spotify API to get track names and artist information, then finds and downloads the closest YouTube match via yt-dlp under the hood [README].

The architecture is honest in a way its competitors often aren’t: it doesn’t pretend to be downloading from Spotify. The README states plainly: “Spooty basically downloads nothing from Spotify, it only gets information from Spotify and then finds relevant and downloads music on YouTube.” [README] That distinction matters both technically (no DRM circumvention) and practically (audio quality is YouTube-capped, not Spotify-master-capped).

The project is built on NestJS (backend) and Angular (frontend), packaged into a single Docker image. It uses SQLite for its database, Redis for job queuing, and FFmpeg for audio format conversion [README]. The developer is Raiper34, a solo maintainer with 4 additional contributors and 23 releases as of this writing. GitHub shows 1,146 stars and 57 forks — meaningful traction for a niche self-hosted media tool, but not a large community [GitHub].

The README carries a prominent legal disclaimer: “Please do not use this tool for piracy! Download only music you own rights! Use this tool only on your responsibility.” That warning is worth taking seriously. Whether downloading a Spotify track you’ve “saved” to your library constitutes owning rights to it depends on jurisdiction and interpretation. If you’re in doubt, consult someone who knows your local copyright law — this review isn’t legal advice.

---

Why People Choose It

There are no independent third-party reviews of Spooty to synthesize. What follows is based solely on the GitHub README and repository data, plus the general context of why people build and use self-hosted music downloaders.

The appeal lands in a specific frustration: Spotify’s offline mode exists, but only inside the app, only while your subscription is active, and only on devices Spotify approves. If your subscription lapses, or Spotify removes a track from their catalog, or you want to play music in a car head unit that doesn’t support Spotify, you’re out of luck. The files never belong to you.

Spooty’s subscription feature is the sharpest differentiator in this category. You can point it at a playlist or artist page and forget it — new releases get pulled automatically. For someone maintaining a local library of followed artists, that’s the difference between a one-time utility and something genuinely useful long-term.

The output format flexibility is also notable: mp3, flac, wav, m4a, aac, opus, vorbis, and alac are all supported. You can set audio quality globally (VBR 0–9 or specific bitrate). If you’re building a FLAC library for archival purposes, this matters [README].

---

Features

Core download capabilities:

• Download individual tracks, full albums, or entire playlists from a Spotify URL [README]
• Subscription mode: monitor a playlist or artist page and auto-download new content as it appears [README]
• Eight output formats: mp3, flac, wav, m4a, aac, opus, vorbis, alac [README]
• Configurable audio quality (VBR 0–9 or bitrate) [README]
• Rate limiting: default 3 YouTube downloads per minute, configurable via YT_DOWNLOADS_PER_MINUTE [README]

Infrastructure:

• REST API (documented in the project) [README]
• SQLite database for job state [README]
• Redis for async job queueing [README]
• Web UI (Angular frontend served by the NestJS backend)
• Docker and Docker Compose deployment [README]

YouTube download flexibility:

• YouTube cookie passthrough via YT_COOKIES environment variable, which can bypass download restrictions for age-gated or region-locked content [README]

What it doesn’t do:

• No multi-user accounts or access controls — it’s a single-user self-hosted tool
• No direct Spotify audio download — everything routes through YouTube matching
• No music tagging/metadata enrichment beyond what the Spotify API returns
• No mobile app

---

Pricing: SaaS vs Self-Hosted Math

Spooty doesn’t have a SaaS offering. It’s free software, MIT-licensed, run entirely on your own infrastructure.

The comparison that motivates using it is Spotify Premium itself:

• Spotify Premium Individual: $11.99/month (as of 2025 US pricing)
• Spotify Premium Duo: $16.99/month
• Spotify Premium Family (6 accounts): $19.99/month

Spotify’s offline download feature is included in any Premium plan — but downloads expire if you go more than 30 days without connecting to the internet, and the files are DRM-locked to the Spotify app. You cannot move them. When you cancel Premium, they disappear.

Spooty self-hosted:

• Software: $0 (MIT license)
• VPS to run it: $4–6/mo (Hetzner, Contabo — a small instance handles this fine)
• Spotify Developer App: free (requires a Spotify account, free or paid)
• Your time: ~30 minutes for initial setup if you’re comfortable with Docker

The math is different from a typical SaaS-replacement comparison because Spooty isn’t a Spotify replacement — it’s a one-time download tool. If you’re building a local archive and then plan to downgrade or cancel Spotify, the relevant comparison is: one afternoon of setup versus perpetual subscription payments for files you never own.

One practical note: the YT_DOWNLOADS_PER_MINUTE default of 3 means a 300-track playlist takes approximately 100 minutes to download. For large libraries, plan accordingly.

---

Deployment Reality Check

Docker is the straightforward path. The entire setup is one docker run command with two required environment variables: SPOTIFY_CLIENT_ID and SPOTIFY_CLIENT_SECRET [README].

The friction is in getting those credentials. Before you can run Spooty, you need to:

1. Go to https://developer.spotify.com/dashboard
2. Sign in with a Spotify account (free account works)
3. Create a new application
4. Copy the Client ID and Client Secret
5. Add a redirect URI: http://127.0.0.1:3000/api/callback (or your instance URL)

This is a legitimate Spotify OAuth application — you’re not bypassing anything. But it adds 10–15 minutes of friction that a typical self-hosted tool doesn’t require. People who bounce off self-hosted tools at the first sign of complexity may not make it through this step.

What you actually need:

• Docker installed on a Linux server or local machine
• A Spotify developer account (free)
• A volume mount for downloaded files
• Port 3000 exposed (or proxied through Caddy/nginx for HTTPS)

What can go sideways:

• The RUN_REDIS=true environment variable tells the backend to start an internal Redis server. This is convenient for Docker but adds memory overhead — if you’re on a 512MB VPS, you’ll want to run Redis separately [README].
• YouTube matching is imperfect. For obscure tracks, live recordings, or tracks with common names, the YouTube match may not be what you expected. There’s no per-download confirmation step in the current UI.
• YouTube rate-limiting and anti-bot measures can cause download failures. The YT_COOKIES option exists specifically to mitigate this, but setup requires extracting cookies from a browser session [README].
• With only 5 contributors and no corporate backing, bug fixes depend on one maintainer’s availability. There are no enterprise support options.

Realistic time estimate: 30–45 minutes for someone comfortable with Docker. Double that if you’ve never set up a Spotify developer app before.

---

Pros and Cons

Pros

• MIT license. You can run it, fork it, modify it, or use it in other projects without restriction [README].
• Subscription mode. Auto-download new releases from playlists or artists — no other tool in this niche handles ongoing monitoring this cleanly [README].
• Eight output formats including FLAC and ALAC. Useful for anyone building a lossless local archive [README].
• Single Docker container. One command, one container, done. No multi-service compose file required for the basics [README].
• REST API. Means you can automate downloads without the web UI [README].
• Active release history. 23 releases, automated changelog generation, and semantic versioning signal a maintained project, not an abandoned one [GitHub].
• Honest technical documentation. The README explains the YouTube-as-source mechanism clearly rather than obscuring it [README].

Cons

• No third-party reviews. No community reputation to evaluate — no Reddit threads, no blog writeups found. Makes it harder to assess real-world reliability at scale.
• Small contributor base. Five contributors means the bus factor is high. If the maintainer loses interest, the project stalls.
• Spotify API dependency for metadata. Even though audio comes from YouTube, you still need a Spotify developer app registration. This creates ongoing API dependency.
• YouTube audio quality ceiling. Source audio is YouTube-encoded, which typically caps at 128kbps for most tracks unless you’re targeting a specific quality level. The FLAC output option doesn’t change the source quality — it just repackages the YouTube audio.
• No access controls. No authentication, no per-user settings, no rate limiting per user. If you expose this to the internet without a reverse proxy enforcing access controls, anyone who knows the URL can queue downloads.
• Legal gray area. The disclaimer in the README is genuine but the “only music you own rights to” carve-out is narrow in practice. Understand this before running it in environments with compliance requirements.
• No tagging/metadata enrichment pipeline. Downloads land in your folder; there’s no Beets or MusicBrainz integration to clean up filenames and embed proper tags.

---

Who Should Use This / Who Shouldn’t

Use Spooty if:

• You have a large Spotify playlist you want to archive locally and won’t do it manually, track by track.
• You want to follow an artist’s releases and have new tracks appear in a local folder automatically.
• You’re comfortable with Docker and creating a Spotify developer app, or willing to follow documentation carefully.
• You need flexibility in output format (especially FLAC or ALAC).
• You understand the legal framework in your jurisdiction and are confident your use case fits within it.

Skip it if:

• You want a completely hands-off experience with no API credential setup — look at spotDL if you want a CLI tool with simpler auth, or Lidarr/Deemix if you’re already running an *arr stack.
• You need reliable audio quality — YouTube source audio is not archival quality regardless of output format.
• You’re running a multi-user household where different family members have different libraries — there’s no account system.
• You need compliance-safe, fully licensed music access — use a service that provides it directly (Spotify, Tidal, Qobuz).
• You want an active community, extensive docs, or paid support — this project has none of those.

---

Alternatives Worth Considering

• spotDL — CLI-first Spotify downloader that also uses YouTube as a source. No web UI, but simpler auth setup and larger community. Good choice if you’re comfortable with the command line and want something battle-tested.
• Lidarr + Deemix — The *arr ecosystem approach. More complex setup, but integrates with your existing Sonarr/Radarr/Jellyfin stack. Better for large libraries where you want consistent tagging and organization.
• yt-dlp directly — If you don’t need the Spotify metadata bridge and already know your YouTube playlist URLs, yt-dlp with a simple cron job does the same job with fewer moving parts.
• Navidrome + Beets — Not a downloader, but a full local music library stack. Pair with whatever download mechanism you choose for a complete self-hosted music experience.
• Plex Pass + Plexamp — If you already pay for Plex and want a polished experience, Plexamp with a local music library gives you Spotify-like streaming from files you own, no gray-area tooling required.

For someone coming specifically from Spotify frustration, the realistic choice is Spooty vs. spotDL. Spooty wins on web UI and subscription automation. spotDL wins on simplicity and community size.

---

Bottom Line

Spooty is a focused, well-built single-purpose tool: paste a Spotify URL, get local audio files. The subscription mode for playlists and artists is the feature that makes it worth using over a CLI alternative — if you want ongoing downloads without manual intervention, nothing in this niche handles that more cleanly. The trade-offs are real: YouTube-quality audio regardless of output format, a Spotify developer app requirement that adds friction, no multi-user support, and a small enough contributor base that long-term maintenance isn’t guaranteed. It’s not the right tool for compliance-sensitive environments or anyone looking for archival-quality audio. But for a hobbyist building a personal local library from their Spotify collection, it delivers on its stated purpose with an honest codebase and a no-nonsense MIT license.

---

Sources

1. Spooty GitHub README — Installation instructions, architecture overview, environment variable reference, legal disclaimer. https://github.com/Raiper34/spooty
2. Spooty GitHub Repository — Stars (1,146), forks (57), contributors (5), releases (23), license (MIT). https://github.com/Raiper34/spooty