SoundStorm, from the top

One login, one search box and one player over a whole home media library - music, films and TV, audiobooks, ebooks, documents and photos - installed by double-clicking a file. This site explains how it is built, starting from the shape of the whole and going down, one level per click, to the decisions inside each part.

What it is

SoundStorm is a front end for a self-hosted media library. Somebody installs it on a computer at home, makes an account, and puts their media in five folders - or drags it onto the window. From then on everybody in the house uses one app, on a computer, a phone or a TV, with one sign-in, and never needs to know what runs behind it.

The person who asked for it put it like this: "an all-encompassing server that can do movies, audiobooks, ebooks, music all together... easy for users to install and then create a login... and put their library into organized folders."

The shape of the whole

Four layers. Everything a person touches is at the top; everything SoundStorm deliberately does not build itself is at the bottom. Each box links to the part of this site that explains it.

The decision that shapes everything

That request sounds like "build a media server". It is not, and the difference is the whole project. Scanning disks, identifying media, keeping metadata and artwork and transcoding video is years of work that mature projects already do well. So SoundStorm owns the layer above: login, search, playback and the bytes. Each backend owns one kind of media and one folder; nothing scans the same folder twice. From the user's seat it is one server - they never learn Jellyfin exists - but Jellyfin still transcodes and Navidrome still scans the music.

If the seams leak, the whole thing is pointless. A result that sends somebody to a backend's own web page means a second login and a visibly different app - and at that point SoundStorm would be a bookmark folder. So the server sits in the data path: every song, film and photo passes through it, signed in as the person asking.

The decisions, and the two that were reversed →

Where to go next

ArchitectureThe layers, a request end to end, what is kept where, the repository. The serverThe Go program at the centre: its API, sign-in, streaming, the library, music, photos, books. BackendsEach media server SoundStorm sets up and drives, and what it learnt about each one's API. AppsThe web app, Now Playing and its visualizers, the reader, Android, iPhone and TVs. SecurityWho it defends against, and ten review passes of what was found and fixed. Running itInstalling, updating, moving computers, reaching it away from home, fixing problems. DevelopmentTwo machines, one branch, how it is tested, and the traps worth knowing.

In numbers

ServerOne Go program, no third-party Go dependencies, embedded web app
BackendsNavidrome, Jellyfin, Audiobookshelf, Immich, Storyteller, AudioMuse-AI - all provisioned with nobody logging in
AppsWeb app (installable), Android (phones and Google/Android/Fire TV), iPhone, Apple TV
InstallDocker Compose behind a double-click installer on Windows, a one-line script on Mac and Linux
Outside servicesNone needed. A small name service gives each install a trusted certificate; lyrics, music discovery and scrobbling are opt-in.