Fastpotify Went From 2,848 to 3,801 Stars in a Week and Our First Build of It Failed
A Rust Spotify client went from 2,848 to 3,801 stars in the seven days we were watching it. We compiled it ourselves: 22 MB of binary against Spotify's 393 MB app bundle, and one dependency that should give you pause.
The WJS Desk
Sep 11, 2026 · 5 min read
We take a snapshot of GitHub's fast-moving repos on a schedule, which means we occasionally get to report acceleration rather than size. On 4 September, crmne/fastpotify sat at 2,848 stars. When we pulled it again on 11 September it was at 3,801. That is 953 stars in seven days, on a repo whose first commit landed on 27 August.
It is a Spotify desktop client written in Rust. That category is a graveyard, so we cloned it, built it, and ran it.
What it actually is
Fastpotify is a native GUI built on egui, using librespot for playback. It registers itself as a Spotify Connect device, so your phone sees it as a speaker, and it can also drive playback on other devices on your network over mDNS. There is no browser engine anywhere in it, which is the entire pitch.
The source is organised the way you would hope. src/player.rs holds librespot playback, mixing, and Connect state; the rest splits along UI and API lines. It is 80 Rust files and 62,954 lines, which is a lot more code than the README's word "lightweight" suggests, though a GUI app is fairly compared only against other GUI apps.
The README is unusually honest about the one thing that will stop most readers: playback needs Spotify Premium. Free accounts can browse and search and nothing else. We do not have a Premium account on the test machine, so we did not test audio playback at all, and every playback claim below is the maintainer's, marked as such.
Our first build failed
The repo pins its toolchain in rust-toolchain.toml to Rust 1.98.0, which is the right call and meant we did not have to guess. We installed it and ran cargo build --release on an Apple Silicon machine.
It died after about 36 seconds:
error: failed to run custom build command for `projectm-sys v1.2.3`
failed to execute command: No such file or directory (os error 2)
is `cmake` not installed?Fastpotify vendors libprojectM, a C++ music visualiser, so a "Rust app" needs CMake and a working C++ toolchain to compile. Nothing in the README's quickstart mentions this. After brew install cmake, the release build completed in 1 minute 34 seconds wall clock (364 seconds of CPU across 8 cores), producing a 23,085,696 byte binary. That is 22.0 MB.
What we measured
We launched the built binary and sampled it. It reached its login window immediately and settled at 201.6 MB resident, holding 0.0% CPU at idle across six samples two seconds apart. That is at an unauthenticated login screen with no library loaded, so treat it as a floor, not a typical figure. The maintainer's README claims 100 to 250 MB in normal use; our floor measurement sits near the top of that range before anything has loaded, which is the one number we would want to see re-measured with a real library attached.
For size, we compared against what is actually on the machine and what Spotify actually serves:
| Measure | Fastpotify | Spotify desktop | ncspot (Rust TUI) |
|---|---|---|---|
| macOS download | 23.9 MB (universal DMG) | 157.8 MB (ARM64 DMG) | 4.4 MB |
| On disk after install | 22.0 MB binary | 393 MB app bundle | not measured |
| Crates in lockfile | 752 | n/a | 595 |
| Rust source lines | 62,954 | n/a | 13,573 |
| Builds without a C++ toolchain | No, needs CMake | n/a | Yes |
The size win is real and large: 393 MB of Spotify.app against 22 MB of Fastpotify is roughly 17 to 1. The losses are just as real. Against ncspot, a Rust client that has existed for years, Fastpotify carries 157 more crates and 4.6 times the source, and cannot be built on a machine with only a Rust toolchain on it. Some of that is the cost of being a GUI rather than a terminal app. Not all of it.
We also pulled release download counts as an adoption signal separate from stars. Version 0.7.1 has 1,007 macOS DMG downloads and 2,313 Windows x86_64 installer downloads. Stars are cheap; those numbers are people who actually wanted the binary.
What it does not do
- Play anything without Spotify Premium. This is the headline limitation and it is Spotify's, not the project's.
- Build without CMake and a C++ compiler, because of the vendored visualiser.
- Guarantee it will keep working. librespot-based clients depend on a protocol Spotify does not support and has broken before.
- Offer any mobile story. Linux, macOS, and Windows only.
- Sit still. Large parts of the README describe behaviour that exists only on
main, after 0.7.1. Features are landing faster than releases.
Who made it, and the dependency nobody mentions
GitHub lists 27 contributors, which sounds healthy until you look at the distribution. Carmine Paolino (crmne) has 399 contributions. The second-highest has 9. In the most recent 200 commits, 174 are his. This is a one-person project that 26 people have sent a patch to.
That alone would be normal for a 15-day-old repo. What raised our eyebrows is what happens when you read Cargo.toml instead of the README. Eight of its dependencies do not come from crates.io at all:
projectm-sys = { git = "https://github.com/crmne/projectm-rs", branch = "respect-cmake-generator" }
librespot-audio = { git = "https://github.com/crmne/librespot", branch = "fastpotify-0.8" }
librespot-connect = { git = "https://github.com/crmne/librespot", branch = "fastpotify-0.8" }
librespot-core = { git = "https://github.com/crmne/librespot", branch = "fastpotify-0.8" }
# ...and four more librespot crates from the same forkThe hidden cost of adopting this: the audio engine is not upstream librespot. It is one person's fork, on a branch named after this app, hosted on his personal account. If that branch goes away or diverges too far to rebase, the project does not just lose a maintainer, it loses the thing that makes sound come out. The 22 MB binary is not the number to worry about. This is.
To be fair to the project: the forks are almost certainly there because upstream librespot moves slowly and Connect support needed patching. That is a reasonable engineering decision. It is still a supply chain with exactly one person in it, and the README does not mention it.
Verdict
Install it today if you have Premium, you already dislike the official client, and you are comfortable that a hobby project might stop working on a Tuesday. It is genuinely well built: pinned toolchain, MIT licence, a docs site, real release artefacts for six platform targets, and a binary that starts instantly and sits at 0% CPU doing nothing. That is more discipline than most repos with ten times the stars.
Wait if you want a client you can stop thinking about, or if you were going to suggest it to somebody who does not read release notes. At 71 open issues, 15 days old, and one load-bearing contributor, this is early.
What would change our mind: the librespot changes landing upstream, so the audio path no longer depends on a personal branch. That single change would move this from "impressive" to "recommendable", and nothing about the star count matters until it happens.
