Songhive — A fully self-hosted and federated music platform https://blog.fabiomanganiello.com/article/Songhive

The problem

If you've ever tried to self-host your music, you've probably noticed that every tool solves exactly one half of the problem.

Media servers (Jellyfin, Navidrome, plain Subsonic) are great at the library half: point them at your FLAC collection, get streaming, transcoding, mobile apps. But they're single-player islands. Nobody else can discover your music, there's no social layer, and sharing a track means copy-pasting a file or a link that probably doesn't resolve outside your LAN, or creating accounts on your server for every person you want to share content with.

Social music platforms (Funkwhale being the closest thing) add the federation half, but the social experience is mostly library-oriented: you follow someone's library and sync their files. It's a distribution network, not a place where people talk about music. Moreover, most of those open platforms were never thought with revenue models in mind. Payments were never integrated. They're mostly places for artists to freely share their creations, not for them to monetize them.

Streaming services (Spotify, Apple Music, TIDAL) are widespread, but they usually don't come with true built-in social features besides following someone else's playlists, or the "Share to Facebook/Instagram/TikTok" button. And consumers don't own anything: the catalog can shrink overnight, and shared URLs can often be viewed only by people who already have an account on the platform. Music creators don't have much of a say either. They get fractions of a cent, they don't fully control distribution (and often they need an intermediary just to distribute their music, which takes a share of the revenue too), and they often have to release to multiple music platforms just because those platforms don't talk with one another. Most importantly, your listening history is the product.

Bandcamp tries to fix some of the issues, namely by putting content creators at the center and letting them own their own sales and monetization process (including sales of things like vinyls, CDs and merchandise). But it's still a centralized service whose ownership changed hands several times. Users and artists are just one round of layoffs away from seeing the platform they invested in rot and/or enshittify, with no direct compatible alternatives. The social media aspect is also not something Bandcamp particularly invested in as well. The focus has increasingly shifted to sales, social interactions are basically limited to a "community" tab on artist pages, where artists can post updates and people can reply to. Any social interactions stay strictly confined to a tab on a centralized platform.

Perhaps the old incarnation of Google Music helped filled an important gap on user-generated content (it allowed users to upload up to 50,000 tracks to the cloud for free, making music collection sitting on old hard drives available on-the-go), but it didn't last long, and it didn't cover any social media and sharing needs.

And MySpace — the thing everyone actually remembers fondly — was never really any of these. It was a place where a band had a page, you could play their song right there, leave a comment, and add them as a friend. Nobody has successfully rebuilt that.

Songhive is an attempt to meet all these needs in one package: a self-hosted music streaming server where tracks, albums, playlists and posts are first-class ActivityPub objects. Think Funkwhale meets Mastodon — your music library lives on your hardware, or in any cloud storage you want to plug to it, but your music (and your posts about music) can travel across the fediverse, be followed from Mastodon, replied to, boosted, and quoted.

Who is this for

• Artists: publish tracks with a "Publish on the Fediverse" checkbox and they appear as playable Audio objects in Mastodon timelines. People can reply, boost and quote them from their existing fediverse account — no new signup required on your side. Your artist page, releases and playlists all expose RSS/Atom feeds, and blogs that support Webmentions will send you a notification when they link to your song. Native integration with Stripe also makes it easier for you to connect a payout account and put some of your tracks or albums for sale. You can choose how much of a paid song you want to share for streaming (only a sample, the full song or nothing), and how much users should pay for it. No shares of your revenue are taken besides the share taken by Stripe to process the transaction.
• Bands who need an easy and flexible way to share their recordings, rehearsals, playlists of covers etc. Those who have played in a band know this issue quite well. Spotify playlists for covers to play are only good as long as everyone in the band has a premium Spotify account. YouTube playlists often result in precious rehearsal time wasted waiting for ads to end. Not to mention those rehearsal.mp3 files shared between WhatsApp chats, emails and Dropbox or Google Drive folders, with no easy way of bringing them all together under the same roof - especially when you're looking for those recordings during a rehearsal. Songhive makes it easier to share whole tracks, albums or playlists with full control over the level of visibility. It makes it easier to integrate 3rd-party music streaming services so you can sync your playlist of covers and easily share it from a proxy platform without everyone having to have a Spotify or TIDAL premium account. It makes it easy to just plug that Google Drive folder where you carelessly dropped all the recordings of your band's rehearsal and sort them, tag them and share them as consistent collections with a single URL.
• Self-hosters / library curators: point Songhive at your local folders, an S3 bucket, a WebDAV/SFTP share, Dropbox, Google Drive — or even import your collections from Jellyfin or TIDAL — and get a full streaming stack with transcoding, Subsonic mobile apps, Last.fm scrobbling, listening stats and automatic MusicBrainz/cover-art enrichment. Fine-grained visibility (private / local / public) means your 4,000-track hoard stays private while the three songs you actually wrote are public. Not only, but Songhive also taps into an issue that open projects like these often fail to address: how to provide incentives to sysadmins and self-hosters to run their servers. Especially when it comes to things like a music streaming server which, in terms of CPU, storage and bandwidth usage, is not free - and often not even cheap. Songhive provides the option for sysadmins to have a Paid registration mode. The admin can decide how much they want to charge users to use their instance and upload music to it, and how often they want to charge them. Subscriptions are handled transparently by Stripe and can be cancelled at any time. And admins can also set user quotas to keep things sane and prevent abuse.
• People who want a MySpace-style music social network: run an instance for your scene, your label, your collective. Users get profiles, statuses with mentions and hashtags, threaded replies, quotes, notifications, and moderation tools (mute/block, reports, instance-level defederation). Your instance federates with Mastodon, so it's not a walled garden unless you want it to be.
• Musicians with a multi-room house or a community radio streak: server-side outputs let playback keep running on the server after you close the tab — cast to Snapcast multi-room speakers, relay to an Icecast station, or host your own HTTP radio mountpoint with fan-out to unlimited listeners.

What you get

The streaming stack

The core is a serious music library and streaming server:

• Library management with artists, albums, tracks, playlists and dynamic radio stations. Uploads get automatic tag extraction, duplicate detection, and metadata enrichment from MusicBrainz and the Cover Art Archive — including cover art and artist images fetched for you.
• Streaming with on-the-fly transcoding (MP3, OGG, FLAC, AAC, Opus), HTTP range requests, and a transcode cache, with per-user/per-role bitrate caps (handy if your uplink or mobile data is precious).
• Subsonic API compatibility, enabled by default. This is the sleeper feature: every Subsonic-compatible mobile/desktop client — Substreamer, Symfonium, Ultrasonic, Supersonic, Tempus and friends — works against your instance out of the box. You get a decade's worth of mature third-party players for free, and API tokens keep your real password out of them.
• Mopidy integration via the mopidy-songhive extension if that's your jam. - Listening history, favorites and scrobbling to Last.fm and Libre.fm out of the box, plus a personal listening-stats dashboard (top artists, calendar and hour-of-day heatmaps, release-year breakdowns) rendered with ECharts.

• Bulk downloads: select tracks/collections and get an async-built ZIP archive.
• Server-side outputs — Spotify-Connect-style. The browser is just a remote control; audio is rendered by the server via a dedicated stream worker. Three providers: an Icecast relay (with live ICY metadata updates), a Snapcast provider for whole-home audio, and native HTTP mountpoints (/streams/<mount>) served directly by Songhive with per-listener cursors over Redis Streams — no external radio server required. Playback keeps playing after you close the tab, and multiple tabs/devices stay in sync.
• Payments support out of the box — set up a Stripe account and connect it to the instance, and configure it as a marketplace account if you also want to allow musicians to wire their payout accounts and sell music through your platform.

The social layer

This is where Songhive diverges from every other self-hosted media server. Federation is full ActivityPub (via the pubby library), and music entities are social objects:

• Every user is an ActivityPub actor, reachable at @user@instance via WebFinger, with Mastodon-style alias URLs. Mastodon users can follow, mention and interact with you from their own client.
• Tracks are Audio objects. Publishing is explicit and opt-in per upload — your private library never leaks to the Fediverse by accident. Published tracks render as playable audio in Mastodon and Akkoma timelines, with descriptions, hashtags and link-backs to the track page.
• Mastodon-style statuses with Markdown, mentions, hashtags, threaded replies, quotes and link preview cards. Reply to a track, boost an album drop, quote-post a playlist, or simply post some words to Mastodon and use it like a normal Mastodon account.
• Funkwhale-compatible music federation: full bidirectional music federation with Funkwhale and other Songhive instances — remote libraries, albums, artists and tracks resolve as browsable resources you can follow and add to your collection.
• Remote discovery: paste a Fediverse handle or URL into the search box and it's dereferenced, cached and browsable — SSRF-guarded and domain-moderated.
• Real notifications over WebSocket (in-app, real-time), with per-type email and daily-digest preferences, plus optional OS-native push via VAPID WebPush.
• Mastodon-grade moderation: users mute/block local and remote actors; admins limit/suspend actors, defederate or restrict instances, and review reports — optionally forwarding them to the reported actor's home instance via ActivityPub Flag.
• RSS/Atom everywhere: every profile, artist, playlist, library, tag and genre has RSS 2.0 and Atom feeds with <link rel="alternate"> discovery, so even non-fediverse readers can subscribe.

Sharing and privacy

• Three-level visibility on tracks, albums, playlists and libraries: private, local (instance-only), or public.
• Share grants (give a specific user access) and revocable share links — a short URL that renders a preview page with an audio player for anyone, content-negotiated so API clients get JSON and crawlers get OpenGraph metadata.
• Embeddables: public tracks and collections embed on any web page via <audio> tags, Markdown links, a <script> widget or a no-JS iframe. Media endpoints send Access-Control-Allow-Origin, so fediverse clients can embed your audio too.
• Webmentions: bidirectional link-backs for public content. A blog that links to your song sends you a notification; content you share or comment on sends a Webmention back to the source. All outbound/inbound fetches on this path are SSRF-guarded.

The platform bits

• Multi-user with open, invite-only, approval-required or closed registration; per-user profile visibility.
• OAuth2 provider for third-party apps, plus API tokens for scripts and Subsonic clients.
• Flexible storage: local filesystem, S3-compatible object storage.
• External libraries — the feature that sells it to people with existing collections. Attach external music storage to a Songhive library: local folders (with a filesystem watchdog that picks up changes automatically), S3, SFTP, WebDAV, Dropbox, Google Drive, or plain HTTP. Entity-backed providers go further: Jellyfin and TIDAL import tracks, albums, artists and playlists as first-class library entries with lazily-fetched contents — audio bytes stay remote and are proxied at play time, so provider credentials never reach the client. Metadata can be written back to the provider, and Dropbox/TIDAL connect via OAuth straight from the settings form.
• Metadata write-back: enriched tags are written into the audio files themselves, using audio-only content hashing — so re-tagging or swapping cover art never changes the stored path or invalidates the content hash. Since it support metadata write-back to the original file, you can also wire your existing music library on an old hard drive and use Songhive to fix broken audio metadata tags.

How it compares

Quickstart

The fastest path is the Docker bootstrap script, which drops a docker-compose.yml, an nginx config, and starter config.toml/.env files into the current directory:

curl -fsSL https://git.fabiomanganiello.com/songhive/raw/branch/main/docker/bootstrap.sh | sh

Set your user's UID/GID in .env (so the bind-mounted volumes stay yours), fill in the few required values in config.toml:

[auth]
secret_key = "..."  # python -c "import secrets; print(secrets.token_urlsafe(64))"

[storage]
local_path = "./data/media"

[federation]
enabled = false
# instance_domain = "music.example.com"  # uncomment to join the fediverse

then:

docker compose up
# Or, if you want to enable local HTTP stream mount points too
docker compose up --profile streams

Create the admin user:

docker compose exec songhive songhive admin create-user \
    --username admin --email admin@example.com --password secret --admin

Open http://localhost:8000/ and start uploading. The web UI, Swagger UI (/swagger-ui/) and OpenAPI spec (/openapi.json) are all served by the same process. There's also a pip install songhive path (the PyPI package ships the built web UI), systemd units under config/systemd/, and an install.sh that wires the whole thing up — see the README for those.

Everything else — federation, Webmentions, RSS feeds, scrobbling keys, registration mode, bitrate caps — is a config knob, and most of it is enabled by default. All config.toml entries can also be overridden with SONGHIVE_* environment variables.

Under the hood

• Backend: FastAPI (REST) mounted inside Tornado via a2wsgi — Tornado natively handles WebSockets, audio streaming with range requests, and HTTP stream mountpoints, while FastAPI handles everything else. (There's a non-obvious reason for the explicit thread pool in the WSGI bridge: without it, a federated fetch that resolves back to your own instance deadlocks the event loop. The architecture doc tells the whole war story.)
• Data: PostgreSQL (SQLite works for small setups) + SQLAlchemy 2 async, Pydantic v2 everywhere, Alembic migrations.
• Async work: Celery + Redis with three queues — celery for interactive work, scrobbles for latency-sensitive submissions, and bulk for the per-item fan-out jobs (a fresh external library sync can enqueue tens of thousands of enrichment tasks; without the split they'd starve scrobbles and federation delivery for hours).
• Storage: content-addressable files (SHA-256) with audio-only hashing, so tag/cover-art rewrites don't move files or invalidate hashes.
• Frontend: Vue 3 + TypeScript + Pinia, fully i18n'd with RTL support.
• Security posture: JWT + opaque rotating refresh tokens, double-submit CSRF, Redis sliding-window rate limiting, SSRF-guarded federation and Webmention fetches with redirect revalidation, Fernet-encrypted provider secrets, RFC 7807 error handling.
• License: AGPL-3.0.

Caveats, honestly

• It's a real stack: Postgres, Redis, a Celery worker, ffmpeg. The Docker compose file makes this a non-issue, but it's not a single static binary. It can run on a RaspberryPi 4 or 5 with decent storage if you want to run it for yourself and your family, but if you want to have more tracks and more users you may need a beefier machine.
• Federation with the big platforms is only as good as ActivityPub support for audio — Mastodon renders playable audio attachments, but it treats Audio as a converted type, so Songhive also emits Note variants when you share a track as a post. The interop details with Akkoma, Funkwhale and friends are handled, but the fediverse music landscape is still young.
• TIDAL imports federate metadata-only (a browse link, not hosted audio) — for obvious reasons the audio bytes stay with the provider.

Links

• 🏠 My personal instance: manganiello.music
• 👤 My Fediverse handle: @fabio@manganiello.music
• </> Code: github.com/blacklight/songhive (canonical forge: git.fabiomanganiello.com/songhive)
• 🏗️ Architecture deep-dive: docs/ARCHITECTURE.md
• 🧩 Mopidy extension: mopidy-songhive