Audiobookshelf: The Self-Hosted Audiobook Server That Finally Replaces Audible
Buying an audiobook on a major platform is not buying an audiobook. It is buying a licence that a company can revoke, region-lock, or quietly downgrade — and the only way to find out is to lose access to something you thought you owned.
There is a specific kind of frustration that only audiobook listeners know. You have spent years and real money building a library. Then a title vanishes because a licensing deal expired. Then an app update removes the feature you used. Then you discover that the 40-hour epic you "bought" cannot be played in the car because the platform's offline mode requires a subscription tier. The files were never yours, so the experience was never yours either.
Audiobookshelf is the open-source answer, and it has quietly become one of the most loved projects in the self-hosted media space: roughly
14,260 GitHub stars,
GPL-3.0,
v2.36.0 released in late July 2026, with commits landing within days of this writing. It is a self-hosted audiobook and podcast server with multi-user support, per-user progress tracking that syncs across devices, automatic library detection, a chapter editor, and open RSS feeds that let you use any podcast client you like.
It is also, by a comfortable margin, the best-executed media server in its niche — and it has a set of sharp edges that will cost you an afternoon if nobody warns you about them first. This is the deep-dive: what it does, what it costs, where your data goes, and the three structural limitations you should know before you start.
1. What Audiobookshelf Actually Is
Audiobookshelf is a
self-hosted server for audiobooks and podcasts, with a web client and official mobile apps.
The concept is familiar if you have run a media server before: point it at a directory of files, and it organises them into a browsable library with cover art, metadata, chapters, and a player. What makes it different from pointing Plex or Jellyfin at the same folder is the depth of the audiobook-specific handling.
It streams every audio format on the fly. MP3, M4B, FLAC, OGG, Opus, WMA — no pre-conversion step, no transcoding pipeline to configure. The file you have is the file that plays.
It tracks progress per user, across devices. Start a book on your phone at 35 minutes in, open the web client on a laptop that evening, and it offers to resume exactly there. For audiobooks specifically this is the difference between usable and not: a 22-hour book is not something you re-navigate by memory.
It finds and manages chapters. Chapters are what make an audiobook navigable, and a huge number of rips and downloads either lack them or have them wrong. Audiobookshelf can look chapters up from an external service, and ships a chapter editor so you can fix them by hand when the lookup fails.
It handles podcasts too. Search, subscribe, and auto-download episodes — meaning the same server that holds your purchased audiobooks can be the thing that fetches your podcasts every morning, on your storage, with your retention rules.
It exposes open RSS feeds. This is the sleeper feature and possibly the best one. Every library, every book, every podcast can be served as a standard RSS feed. Point any podcast app at it — the one you already use, on any platform — and your audiobooks show up as "podcasts" you can stream or download for offline listening. No proprietary client required, ever.
2. Why This Matters More for Audiobooks Than for Music
People who self-host music are usually doing it for convenience or cost. People who self-host audiobooks are often doing it because of ownership, and the distinction is worth spelling out.
Music streaming at least gives you access to everything while you pay. An audiobook platform typically sells you individual titles — a credit system, a per-book purchase — which
feels like ownership in a way a subscription does not. Then you discover the terms: the licence is revocable, tied to your account, and non-transferable. If the account is closed, region-locked, or the title is pulled, the purchase evaporates.
DRM means you cannot make your own archival copy. With a CD, ripping is a legitimate personal-use step that produces a file you control forever. With a DRM'd audiobook, the decryption key lives with the platform, so there is no durable copy to make.
Audiobooks are expensive and long. A 30-hour book is a real investment of both money and time. Losing access to it stings in a way that losing access to an album does not, and re-buying is not a trivial matter.
The legitimate sources now exist. This is the part that has changed. DRM-free audiobook stores are mainstream — Bandcamp-adjacent sellers, direct-from-publisher shops, Humble Bundle book bundles, and library-adjacent services all sell or lend files you can actually keep. Once the files are yours, the only missing piece is a good server, and that is the gap Audiobookshelf fills.
The honest framing, then: Audiobookshelf does not solve acquisition. It solves
custody. If your library currently lives entirely inside a platform's app, this is what lets you move it somewhere nobody can revoke — and it makes buying DRM-free going forward feel like a rational choice rather than a sacrifice.
3. How It Works Under the Hood
The architecture is worth a paragraph because it explains both the project's strengths and its constraints.
The server is
Node.js on Express 4, a deliberate and somewhat conservative choice that keeps the codebase approachable. Data lives in
SQLite via the Sequelize ORM — which is why the server is trivial to deploy and also why very large multi-user deployments hit a ceiling. Real-time features use
Socket.IO, which is why progress sync and library updates feel instant, and also why your reverse proxy must support WebSockets.
FFmpeg is invoked as a child process for metadata extraction, transcoding when needed, and merging multiple files into a single M4B.
Passport with JWT and
openid-client handle authentication, including OIDC — so you can put Audiobookshelf behind an external identity provider rather than managing yet another password.
The client is
Nuxt 2 / Vue 2 with Tailwind, built as a static bundle and served by the same Express process. There is no separate frontend service to run. It is a Progressive Web App, which means installing it on a phone home screen gives you something close to a native app experience even where no official app exists.
One detail that tells you something about the project's seriousness: the Docker build pulls in a custom SQLite extension for
Unicode-aware collation, so libraries with Japanese, Hebrew, or Arabic titles sort correctly. That is the kind of thing a hobby project does not bother with.
4. Deployment Walkthrough
The standard Docker Compose setup:
``
yaml
services:
audiobookshelf:
image: ghcr.io/advplyr/audiobookshelf:latest
container_name: audiobookshelf
restart: unless-stopped
ports:
- "13378:80"
volumes:
- ./audiobooks:/audiobooks
- ./podcasts:/podcasts
- ./metadata:/metadata
- ./config:/config
`
Port 13378 is the default. The four volumes each matter:
/audiobooks
— your book library.
/podcasts
— downloaded podcast episodes.
/metadata
— cover art, backups, and the daily metadata backups the server writes automatically.
/config
— the database and configuration.
Get these right the first time. The most common regret is putting /metadata
somewhere ephemeral, which throws away your artwork cache and the automated backups.
On first launch you create the admin account through the web UI. Then you add a library: give it a name, pick a type (Books or Podcasts — this is fixed per library and cannot be changed later), and point it at a folder inside the container.
Resource usage is modest for a personal library — a Node process with SQLite. On a Raspberry Pi 4 with the library on a USB SSD it runs fine for one or two users. The two things that will make it feel slow are a huge library on a spinning disk, and an initial scan over network-mounted storage.
5. Library Structure: The Part That Breaks People
This is the single most important section in this article, and the one most setup guides skip.
Audiobookshelf expects a specific directory structure, and deviating from it produces a mess. For a multi-file book:
`
/audiobooks/
Brandon Sanderson/
The Way of Kings/
Part 1.mp3
Part 2.mp3
Part 3.mp3
Someone Else/
A Single File Book.m4b
`
Author directory, then book directory, then files. Single-file books can live directly in the author folder.
What happens if you get it wrong:
- Everything in one flat folder — the scanner cannot infer book boundaries, so you get one entry with dozens of unrelated chapters, or a library full of "Unknown Author."
- Inconsistent nesting — some books import fine, others split into multiple partial entries, and you spend an evening manually merging them.
- Metadata that contradicts the structure — the scanner and the embedded tags disagree about what a book is, producing duplicate or orphaned entries.
- Non-Latin characters and odd spacing — usually fine, but inconsistent author naming across directories creates two "authors" for one person.
The fix is to sort the filesystem before the first scan. Ten minutes renaming directories saves an evening of cleanup, because re-scanning a badly structured library does not necessarily undo the damage — you may have to delete the library and re-add it, which loses progress data.
The other structural rule: choose the library type carefully. A library is Books or Podcasts. Audiobooks in a Podcasts library behave like podcast episodes — chronologically ordered, no chapter handling — which is wrong for a novel.
6. Metadata, Chapters, and Where the External Calls Happen
Audiobookshelf pulls metadata and cover art from multiple providers, and resolves chapters through the Audnexus API (a community-run Audible metadata service). This is what turns a folder of MP3s into a library with proper covers, series information, narrators, publishers, and chapter lists.
The workflow that works:
1. Add the library and let the initial scan finish.
2. Run a metadata match on the books that came in thin. The UI lets you search providers and pick the right match rather than accepting the first guess.
3. Fix chapters where the lookup failed. The chapter editor lets you add, move, rename, and delete chapter markers, and save them back into the file if you want them embedded.
Two things to know. First, external metadata providers mean outbound requests from your server. Each match attempt tells a third party what title you hold. For most people this is a fine trade, and it is the same trade every media server makes. If the reason you self-host is that nobody should know what you listen to, you should know this is happening and consider supplying metadata manually.
Second, chapters matter more than you think. A 20-hour book without chapters is nearly unnavigable — you cannot find the section you want to re-hear. Spending the time to get chapters right is the difference between a library you use and a library you admire once and abandon.
The M4B merging tool is worth mentioning here: if you have a book as a dozen MP3s, Audiobookshelf can combine them into a single M4B with embedded chapters and cover art. This is genuinely convenient for archival tidiness, though it is also a destructive-feeling operation on files you care about — keep your originals until you have verified the merge.
7. Podcasts: The Half Nobody Talks About
Most people install Audiobookshelf for books and then discover the podcast side is nearly as good.
You search for a podcast, subscribe, and it downloads new episodes automatically on a schedule. You set retention rules — keep the last N episodes, delete after M days, or keep forever. Everything lands on your own disk rather than in a client's cache that gets cleared.
The reasons this beats using a podcast app directly:
You own the episodes. A podcast that goes offline, changes its feed, or gets retro-edited stops being available to everyone else. If you downloaded it, you still have it.
Storage is predictable. Automatic download plus retention rules means your disk usage stops growing without bound, which is the problem with podcast clients that cache everything forever.
Listening position syncs with your audiobooks. One app, one set of progress state.
The open RSS feed works the other direction too. You can subscribe to your Audiobookshelf podcast library from any podcast client, which means you are never locked to the official apps.
8. Multi-User and Progress Sync
For a household, this is where Audiobookshelf earns its place.
Each user has their own account, their own progress per book, their own playlists, their own playback speed preferences, and their own listening statistics. Nobody's position in a shared book interferes with anybody else's, and you do not inherit your partner's half-finished true-crime backlog on your home screen.
Permissions are granular: who can download, who can upload, who can edit metadata, who can access which libraries. A kids' account that can stream but not download is a reasonable configuration, as is a guest account limited to one library.
Progress sync across devices works through the server, so it requires no cloud. Start on a phone, continue on a tablet, finish on a laptop — the position is server-side state, not a per-device guess.
This is also the feature that makes the "family media server" case work rather than merely function, and it is one of the reasons the project has grown so steadily despite being smaller than the big general-purpose media servers.
9. Mobile Apps and the iOS Problem
There is an official Android app, and it is good. There is an official iOS app, and it is in beta.
The iOS situation deserves specifics because it is the most common source of disappointment: the iOS TestFlight beta has been full, because Apple caps TestFlight at 10,000 external testers. New users may not be able to join, and there is no way around the cap — it is an Apple policy, not a project decision.
If you are on iOS and cannot get into the beta, you still have two working paths:
The PWA. Add the web client to your home screen and it behaves much like an app, including offline-ish behaviour for playback that is already buffered. It is genuinely usable, if less polished than a native client.
Any podcast client via RSS. Point your existing podcast app at your library's RSS feed and your audiobooks appear as podcasts. This is the path many iOS users end up on, and it works with whatever app they already like. It is also the strongest argument for the open-RSS decision: no client, official or otherwise, can ever be a lock-in.
On Android, the official app handles offline downloads, playback speed, sleep timers, Chromecast, and Android Auto. It is a complete client, and it is the best experience available.
10. Ebooks: Real, But Know What You're Getting
Audiobookshelf supports EPUB, PDF, CBR, and CBZ, with a built-in ereader in the web client, and the ability to send books to a device — most usefully, to a Kindle via email.
This is genuinely nice if you have a modest ebook collection and do not want a second server. Keep expectations calibrated:
- The ereader is basic. Functional, not a replacement for a dedicated reading app.
- There is no real library management for ebooks on the level of a purpose-built tool — no complex collections, no reading statistics worth the name, no annotation sync.
- Comic support (CBR/CBZ) is present but rudimentary compared to dedicated comic servers.
- Sending to Kindle works via email, which means outbound mail with your files attached — worth knowing if you were hoping for a fully local pipeline.
If ebooks are your primary medium, use the right tool. If they are an adjunct to a mostly-audio library, having them in the same place is a genuine convenience.
11. The Honest Limitations
The directory structure is strict and unforgiving. Covered in section 5; it is the number-one cause of a bad first experience.
The reverse proxy subfolder is fixed at /audiobookshelf
and cannot be changed. If your proxying scheme assumes configurable subpaths, this will annoy you. Hosting at a subdomain avoids the issue entirely.
WebSockets are mandatory. A reverse proxy that does not forward WebSocket upgrades produces a client that loads and then silently fails to sync.
SQLite is the only database. Fine for personal and household use; a ceiling for large concurrent deployments.
The iOS app is beta and effectively capacity-capped. No workaround.
Ebook support is basic. Do not migrate your reading life into it.
There are over a thousand open issues. This is a sign of an active project with a lot of user input, not necessarily of poor quality, but it does mean you will eventually hit an edge case that is known and unfixed.
Metadata lookups leave your network. Configurable, but on by default.
It is a young project with a small core team. Started in 2021, hugely improved since, still moving fast — which means breaking changes happen more often than in a settled codebase.
12. What It Costs
| Item | Cost |
|---|---|
| Audiobookshelf license | $0 (GPL-3.0) |
| Server (hardware you own) | $0 |
| Storage for your library | Your existing disks |
| Audiobooks | Whatever you pay, DRM-free |
| VPS (optional, for remote access without a VPN) | ~$5–15/month |
| Total marginal | $0 |
The comparison is against a credit-based subscription: roughly $15/month for one credit on the major platform, which is one book. Over a year that is twelve books you do not own versus, potentially, twelve books you do — assuming you buy DRM-free at comparable prices, which is increasingly the norm.
The honest counterweight: the major platforms have enormous catalogues and produce exclusive content you cannot buy DRM-free at any price. For many listeners the rational answer is both — buy DRM-free what you want to keep forever, and use whatever else for the rest.
13. Where Your Data Lives
Self-hosted means your files, your database, your progress, your artwork cache — all on disks you control. Nothing about your listening is reported anywhere.
The outbound calls to know about:
Metadata providers. Title and author lookups for matching, and cover art fetching. Each is a request that reveals a title in your library.
Audnexus for chapters. Same consideration.
Podcast RSS fetching. Your server polls feeds you subscribed to, which reveals your subscription list to those publishers — exactly as any podcast client would.
Email-to-Kindle. Files you send leave your server as email attachments.
None of this is unusual or hidden; it is the standard set of trade-offs for a media server. The point is that it is opt-out-able in a way that a commercial platform's data collection is not.
14. Audiobookshelf vs Plex vs Jellyfin vs Audible
vs Plex. Plex added audiobook support and it works, but it is a general-purpose media server with an audiobook feature rather than an audiobook server. Plex's model also involves centralised authentication and a hosted metadata layer, which is at odds with the ownership thesis. It is the right choice if you already run Plex for video and want one app for everything.
vs Jellyfin. Same category as Plex, fully open source, and a strong general-purpose server. Audiobook handling is less deep than Audiobookshelf's — chapter management and progress semantics are the difference. If your library is mostly video with some audiobooks, Jellyfin. If it is mostly audiobooks, Audiobookshelf.
vs Booksonic and older audiobook servers. Largely historical now; Audiobookshelf superseded them on client quality and active development.
vs Audible. Not a fair comparison and that is the point. Audible has a catalogue nobody can match and conveniences nobody can replicate. It also gives you nothing you keep. Audiobookshelf has no catalogue at all — it serves what you already have — but what you have, you keep.
15. Who Should Not Self-Host Audiobookshelf
- Anyone whose entire library is DRM'd platform purchases. There is nothing to serve. Buying DRM-free going forward is the prerequisite.
- Anyone who will not sort their filesystem first. The structure requirement is not optional.
- iOS-only households that need a polished native app today. The beta cap is real; PWA and RSS are workable but different.
- Anyone who wants a serious ebook library. Use the right tool.
- Anyone uncomfortable with a fast-moving young codebase. Things change.
- Anyone who needs a zero-maintenance appliance. It needs a proxy, backups, and occasional attention like any other server.
16. Getting Started Sensibly
1. Sort your library directory structure before installing. Author folders, book folders, consistent naming. Do this first; everything downstream depends on it.
2. Deploy with all four volumes on persistent storage. Especially /metadata
and /config
.
3. Add one library and let it scan completely before judging anything. Initial scans on large libraries take real time.
4. Fix metadata on the worst offenders first — the books you will actually listen to soon — rather than trying to perfect 400 entries in one sitting.
5. Get chapters right on whatever you are currently listening to. Immediate payoff.
6. Set up the RSS feed and try it in your existing podcast app. This is the fastest way to understand why the open-feed design matters.
7. Then decide about remote access, users, and podcasts.
17. Remote Access Without Regret
As with every self-hosted service, the question is not whether you can reach it from outside your house, but how.
Best: a tailnet. Put the server on your mesh network and the apps reach it as if local, with no public exposure at all. For a household this is the right answer and it takes minutes.
Acceptable: reverse proxy with TLS. If you need to share with people who will not install a VPN, put it behind a proxy with automatic certificates. Remember two things: WebSocket support is mandatory, and the subfolder is fixed to /audiobookshelf
— use a subdomain to avoid fighting that.
Avoid: port-forwarding the container directly. It is a Node application holding your media and a user database, exposed to the internet, with whatever the current release's security posture happens to be.
Whichever you choose, use the OIDC support if you have an identity provider, and give each household member their own account rather than sharing one.
18. Troubleshooting
The scan finishes and the library is empty or nonsense. Directory structure. Almost always. See section 5.
Everything shows as "Unknown Author" or "Unknown Book." Missing or contradictory embedded tags, plus a structure the scanner could not use. Fix the structure, then re-match metadata manually.
The web client loads but nothing syncs or updates. Your reverse proxy is not forwarding WebSocket connections.
Progress does not resume between devices. Confirm you are logged in as the same user on both, and that the server is reachable — progress is server-side, so an offline client cannot report it.
Playback stutters on mobile. Usually network, not the server. If it happens on a good connection, check whether the source file is a very high-bitrate FLAC being streamed over a slow uplink.
Cover art is missing after an upgrade. The /metadata
volume was not persistent.
Duplicate entries for one book. Partial imports from a bad structure, or a file that was moved mid-scan. Delete the library entry and re-add after fixing the folder layout.
19. Backups and Operations
Two categories, as always.
Your media files. The irreplaceable part. Your audiobook purchases and rips need a real backup — a second disk at minimum, ideally an offsite copy. A single drive holding a decade of audiobooks is one failure from silence.
The /config
and /metadata
directories. The database holds users, progress, playlists, and library state; /metadata
holds cover art and the server's own daily backups. Losing them means a rescan and lost listening history — annoying rather than catastrophic, but progress data accumulates meaning over years.
Audiobookshelf writes automated daily metadata backups into /metadata/backups`, which is a thoughtful touch. Confirm they are actually being written and that the directory is included in your backup routine, then stop thinking about it.
Upgrades: read the release notes. It is a fast-moving project, and the occasional release changes behaviour in ways that matter for existing libraries.
20. Three Setups Worth Copying
The commuter. One Pi or mini-PC, a USB SSD with a few hundred hours of audiobooks, the Android app with downloads for the train, and the whole thing on a tailnet. Total marginal cost zero if you already own the drive. This is the setup that makes a purchased library feel like a subscription you control.
The household. Same box, per-user accounts, a shared library plus a kids' library with restricted permissions, and a podcast library with auto-download and 30-day retention. Everyone's progress is their own. This is where the multi-user design pays off.
The archivist. Larger library, careful directory structure, chapters corrected on everything, M4B merges for tidiness, metadata providers disabled in favour of manual entry, and the whole thing backed up offsite. More work, and the only setup where the privacy story is airtight.
21. Where the Files Actually Come From
Audiobookshelf is a server, not a shop, and the most common way the project disappoints people is that they install it and discover they have nothing to put in it. Acquisition is a separate problem, and it is worth being concrete about the legitimate sources.
Libro.fm is the one most ex-Audible listeners land on. DRM-free files, a portion of each sale goes to an independent bookstore you choose, and the catalogue overlaps heavily with the mainstream releases. You download actual files. This is the closest thing to "Audible, but you own it."
Humble Bundle book bundles periodically include audiobooks, usually DRM-free, at prices that make building a starter library almost free. The catalogues skew toward genre fiction and non-fiction, but a couple of bundles fills a library fast.
Publisher-direct and author-direct sales are increasingly common, particularly in genre fiction. Buying from the author is both the best economics for them and the cleanest file for you.
LibriVox deserves a special mention as a starting point. Volunteer-read recordings of public-domain works, completely free, completely legal, and completely DRM-free. The production quality varies with the reader, and the catalogue is old — Dickens, Austen, Doyle, and a great deal of nineteenth-century fiction nobody assigned you in school. If you want to test-drive Audiobookshelf before spending anything, LibriVox gives you hundreds of hours to do it with.
Physical media you already own. Library book sales and second-hand shops are full of audiobook CD sets for very little money. Ripping them produces files with the same permanence as a ripped music CD, and the quality is often better than a heavily compressed download.
What does not work, and what to know about it. Library lending apps use DRM by design; you cannot move those files into a personal server, and you should not try. Stripping DRM from a purchase you made is technically possible and legally fraught — it typically violates the terms you agreed to and, in many jurisdictions, crosses into circumvention of a technological protection measure. I am not going to pretend it does not happen, but it is not the foundation I would build a library on, and it is not something a guide should quietly encourage.
The practical advice is the same as for any media server:
build the library first, install the server second. Spend a few months buying DRM-free what you actually want to hear, and set up Audiobookshelf when you have enough to make it worth the evening. Installing it into an empty directory is how a good tool gets abandoned.
22. Storage: The Number People Underestimate
Audiobooks are large, and a library grows faster than people expect. A 12-hour book at a reasonable bitrate is a few hundred megabytes; a 40-hour epic in M4B approaches a gigabyte. Fifty books is tens of gigabytes. Two hundred books with some high-bitrate rips is comfortably into the hundreds.
That has three practical consequences.
Plan the disk before you need it. Moving a 400 GB library to a larger drive is an afternoon you will not enjoy, and it interacts badly with the strict directory structure — a partially completed move can produce duplicate or broken entries.
Decide your quality policy early. If you are ripping, choose a target bitrate and stick with it, because a library of mixed 64 kbps and 320 kbps files is a library where quality feels random. For spoken word, moderate bitrates are genuinely indistinguishable for most listeners, and the storage savings across a large library are enormous.
Account for the podcast half separately. Auto-downloading a dozen podcasts weekly is real, continuous growth. Retention rules are not optional housekeeping; they are what keeps a 2 TB drive from filling with episodes you will never hear.
None of this is difficult. It is just the kind of arithmetic that is much cheaper to do before the library exists than after.
23. The Verdict
Audiobookshelf is the best thing available for owning an audiobook library, and it wins by understanding the medium rather than treating audiobooks as music with extra steps. Chapters, progress sync, multi-user state, open RSS feeds, and podcast management are the features that matter, and they are all executed properly. GPL-3.0, active development, and no paid tier mean the project has no reason to hold anything back.
The limitations are real and mostly structural: the directory layout is strict, the reverse proxy subpath is fixed, SQLite caps the ceiling, and the iOS app is capacity-limited by Apple rather than by the project. None of these are reasons to avoid it — they are reasons to know what you are signing up for before you spend a weekend on setup.
The core proposition survives every caveat: the audiobooks you bought are files on your disk, nobody can revoke them, and the server that plays them is yours.
Related
Comments (0)
No comments yet. Be the first to comment!