I want to build and self-host a Spotify replacement

Grok 4.1 Fast

Vote: Yes

The question is about building and self-hosting a Spotify replacement, which is highly feasible using mature open-source tools like Navidrome, Funkwhale, Jellyfin, or Subsonic. These provide streaming, playlists, mobile apps via Subsonic API, and library management with Lidarr—replicating Spotify's core for personal use without coding from scratch. Gemini 3.1 Pro's B vote assumes 'build from scratch,' but the query doesn't specify that; self-hosters routinely 'build' by deploying these stacks on Raspberry Pi/NAS with Docker. Thousands succeed per r/selfhosted, gaining privacy, no subs, and control over owned music (CD rips, DRM-free buys). Others (GPT-5.4, GLM 4.5, Claude Opus 4.6) reinforce A: legal for personal libraries, low cost, rewarding. Tradeoffs like no vast catalog/AI are acknowledged but irrelevant for sovereignty-focused users. Gemini's timesink critique applies to greenfield dev, not this ecosystem. Vote A: proven, practical empowerment.

GPT-5.4

Vote: Yes

I maintain vote A. The strongest objection from Gemini is really an argument against building from scratch to match Spotify at global-commercial scale. I agree with that limitation. But the question as phrased is broader: a self-hosted Spotify replacement for your own library or community is absolutely achievable, and existing open-source servers prove it. That matters because the practical interpretation of this question is usually about replacing the user experience of streaming your own music, not recreating Spotify’s licensing business, recommendation stack, and worldwide catalog. On that practical reading, the answer is yes. The A-side arguments are more grounded in real implementation paths: Navidrome, Funkwhale, Jellyfin, Airsonic/Subsonic clients, Docker deployment, metadata indexing, playlists, transcoding, and multi-user access. Those are the core features people actually need, and they already exist or can be assembled. So the correct final answer remains yes—with the clear caveat that you can build a technically similar self-hosted music platform, but not realistically reproduce Spotify’s licensed catalog and platform scale by yourself.

Claude Opus 4.6

Vote: Yes

I'm maintaining my vote of A. Gemini 3.1 Pro raises a fair point about the distinction between 'building from scratch' versus 'using existing self-hosted solutions,' but I think this is a semantic distinction that doesn't change the answer. The question says 'build and self-host a Spotify replacement' — and deploying, configuring, and maintaining a self-hosted music streaming stack absolutely counts as 'building' in common parlance. Nobody interprets this as writing a streaming platform from scratch in assembly. Gemini's argument actually reinforces the Yes position: they acknowledge that excellent tools like Navidrome, Jellyfin, and Plex exist and work well. That's precisely why the answer is Yes — the ecosystem is mature enough that this is a practical, achievable project. The concerns about missing Spotify's catalog and discovery algorithms are valid but beside the point. The user explicitly wants to self-host, which means they've already made a values-based decision prioritizing ownership and control over convenience features. We should respect that intent rather than second-guess it. All four other models essentially agree on the facts: it's feasible, good tools exist, and the tradeoffs are manageable. The only disagreement is whether to encourage or discourage the user, and I firmly believe we should encourage someone pursuing a well-supported, rewarding self-hosting project.

GLM 4.5

Vote: Yes

After carefully reviewing all arguments, I maintain that building and self-hosting a Spotify replacement is a feasible and rewarding project. While Gemini 3.1 Pro makes valid points about the challenges of replicating Spotify's discovery algorithms and catalog from scratch, this interpretation of 'building' is unnecessarily narrow. The most practical approach leverages mature open-source solutions like Navidrome, Funkwhale, or Jellyfin—tools that handle the core streaming functionality while allowing customization. The majority of models (GPT-5.4, Grok 4.1 Fast, Claude Opus 4.6) correctly identify that self-hosting music isn't about recreating Spotify's entire commercial infrastructure but about gaining ownership and control over your personal music experience. For anyone concerned with privacy, data ownership, and avoiding subscription fees, self-hosting provides tangible benefits that far outweigh the relatively minor setup challenges. The self-hosted music ecosystem is mature, well-documented, and actively maintained—making this one of the more approachable self-hosting projects available.

Gemini 3.1 Pro (changed mind)

Vote: Yes

I am changing my vote to A. In the first round, my primary objection was based on a literal interpretation of the word "build"—meaning writing a streaming engine, mobile apps, and backend database entirely from scratch. However, as Claude Opus 4.6 and the other models effectively pointed out, "building and self-hosting a Spotify replacement" in the self-hosted community typically refers to assembling and configuring a technology stack (using Navidrome, Jellyfin, or Funkwhale alongside library managers like Lidarr) to replicate the Spotify experience. Viewed through this lens, creating your own streaming service is not only highly feasible but an incredibly rewarding project. The ecosystem for self-hosted audio is mature, well-documented, and robust. It solves the genuine problems of platform lock-in, privacy concerns, monthly subscription fees, and unexpected catalog removals. Since my recommended solution (deploying these existing open-source tools) perfectly aligns with what it actually means to "build and self-host" in this context, I agree that the answer is an emphatic Yes. I yield to Claude Opus 4.6 for framing this project as a practical assembly of excellent, mature open-source tools rather than a from-scratch coding nightmare.

Final Summary

The AI Roundtable initially split 4-1, with Gemini 3.1 Pro standing as a lone dissenter warning that building a Spotify clone from scratch would be a 'massive, endless timesink.' However, Claude Opus 4.6 and Grok 4.1 Fast reframed the debate by pointing out that 'building' in the self-hosting community refers to assembling mature open-source stacks like Navidrome and Jellyfin rather than writing code from scratch. This semantic pivot convinced Gemini to abandon its skepticism and join the consensus, concluding that the project is an achievable path to digital sovereignty.

All 5 models agreed on "Yes" after discussion

Strongest Arguments

• Yes: The self-hosted music ecosystem is so mature that 'building' a replacement is a practical assembly of proven tools like Navidrome and Lidarr, providing full library ownership without requiring the user to write a single line of streaming code.

Key Turning Points

• Claude Opus 4.6 clarified that 'building' in a self-hosting context means configuring existing open-source tools rather than greenfield software development, dismantling Gemini 3.1 Pro's primary objection.