Yours for Life, Actually: A Self-Hosted Audiobook Pipeline for the Whole Family
“Yours for life” should actually mean yours
Audible’s pitch is that a book you buy is yours for life. I take that seriously enough to want actual control over the files, not just an app license — and I wanted to share that library with family without adding anyone to my real Amazon account. Audiobook Pipeline is the setup that gets there: everyone gets their own account and their own listening progress, without anyone touching my Audible login.
What it does
OpenAudible logs into an Audible account (or several — a household with more than one subscriber can attach all of them), tracks the full purchased library, and downloads + converts each title from Audible’s DRM’d format into a standard, DRM-free MP3 or M4B, complete with cover art and metadata. A symlink step then publishes only the finished files into a separate library folder — Audiobookshelf, the actual family-facing server, never touches Audible credentials or OpenAudible’s working folder at all. Audiobookshelf serves that folder as a real multi-user app: individual logins, per-person progress that syncs across devices, offline downloads, the works.
The isolation decision that mattered most
The deliberate separation between “owns the Audible account” (OpenAudible) and “serves the listeners” (Audiobookshelf) is the actual design decision here, not an incidental detail. Family members get their own Audiobookshelf accounts with zero path back to my Audible credentials — the symlink step is the isolation boundary. Real files exist exactly once in OpenAudible’s private folder; only pointers get duplicated into the public library, which is also what keeps storage sane once a library gets into the hundreds of gigabytes.
The gotcha that would’ve broken the whole automation plan
The pipeline’s core assumption — that a script can symlink a finished file straight from OpenAudible’s folder into the public library — quietly doesn’t hold on every filesystem. Real symlinks failed outright with “Operation not supported” over CIFS/GVFS network storage. I caught this by testing one real symlink manually before building any automation around it, which turned out to matter: the actual fix was SSHing directly into the NAS and creating the symlink there against its own local filesystem path, rather than through the network-mounted path a script would naturally use. Finding that out early, with one manual test, was a lot cheaper than discovering it after building a whole automation script around an assumption that didn’t hold.
What it demonstrates
This is a real example of designing for trust boundaries even in a personal project — “who can see what” mattered enough here to shape the architecture (separate folders, one-way symlinks, zero credential exposure) rather than just sharing a login and calling it done. The network-mount gotcha is also a good example of validating an assumption cheaply (one manual symlink test) before building automation on top of it — a habit that pays for itself far more than the five minutes it costs.
Part of the Homelab AI Blueprints series — see all nine blueprints for building and operating a self-hosted, AI-agent-run home server.