How I self-host audiobooks, ebooks, and comics
A practical look at the NAS, Docker services, and mobile apps behind my self-hosted audiobook, ebook, and comic library.
I was tired of paying monthly subscriptions and still feeling like I had little control over my own library.
Subscription services are convenient, but that convenience lasts only while you keep paying. Titles can disappear, applications can change, and even purchased media often remains tied to the company that sold it. I wanted my books stored as ordinary files on hardware I control, available through applications I chose.
That led to the setup I use today:
- Libation creates local copies of my Audible purchases.
- BookOrbit organizes the collection and handles metadata.
- Audiobookshelf presents the library for listening and reading.
- AudioBooth is the iOS client I use on my iPhone and iPad.
- A NAS stores the actual media files.
- Docker runs the server applications on a separate Linux machine.
At the time of writing, Audiobookshelf has indexed 315 audiobooks, 66 ebooks, and 215 comics.
This is the first post on my DBOTech blog, so it seems appropriate to start with a system I use almost every day.
Why I self-host my library
The main reason is control.
A subscription does not give me a library. It gives me temporary access to someone else's library. Even when I purchase a title, the experience is often designed to keep me inside a particular storefront and its applications.
I wanted to choose:
- Where my books are stored
- Which applications can access them
- How the folders and metadata are organized
- Whether a title can be downloaded for offline use
- What happens when I stop paying for a service
- How long I can keep the files
Self-hosting moves those decisions back under my control.
It also moves the responsibility back under my control. I have to maintain the server, storage, containers, metadata, and backups. If something breaks, there is no customer support department to blame. That trade is worthwhile to me because the files remain usable even if I replace every application around them.
A note about where the books come from
My audiobooks are purchased through my Audible account. I use Libation to create local, DRM-free copies of those purchases.
Every audiobook in this setup is completely legal and purchased by me. Obviously. The fact that I prefer files I can actually back up is between me and my NAS.
My ebooks and comics come from a mix of places online. I am not turning this post into a sourcing guide; the interesting part is what happens after a file reaches my library.
Regardless of where a file starts, it eventually ends up in one of three directories:
media/
├── audiobooks/
├── books/
└── comics/Those directories are the foundation of the whole setup.
The overall design
The applications and media are deliberately separated.
The books live on my NAS. Audiobookshelf and BookOrbit run as Docker containers on another Linux machine. The server mounts the NAS storage and passes the three media directories into both containers.
Audible purchases
|
v
Libation
|
v
NAS media storage
├── audiobooks/
├── books/
└── comics/
|
+----------------------+
| |
v v
BookOrbit Audiobookshelf
organization, library browsing,
metadata, and listening, and
future syncing basic reading
|
v
AudioBooth
iPhone and iPadThe NAS contains the authoritative copy of each media file. I do not maintain a separate copy for BookOrbit and another for Audiobookshelf. Both applications see the same folders.
Configuration and databases stay outside the media directories. This means I can rebuild a container without touching the books themselves.
Audiobooks: Audible to Libation to the NAS
Most of my audiobook collection comes from Audible.
Audible works well as a store, but I do not want my purchased books to be usable only through its application. I use Libation to download the books from my account and remove the DRM. The resulting files are written to the audiobook directory on my NAS.
Libation runs separately from the Docker services. Its job is simply to turn an Audible purchase into a local audiobook that normal media applications can use.
The collection contains both M4B and MP3 audiobooks. I prefer M4B when it is available because it can store the audio, chapters, cover, and metadata in one file. Some books still arrive as multiple MP3 files, and Audiobookshelf handles those as well.
A typical directory might look like this:
audiobooks/
├── Author Name - Book Title/
│ ├── Book Title.m4b
│ ├── cover.jpg
│ └── metadata.json
│
└── Another Book/
├── Part 01.mp3
├── Part 02.mp3
├── Part 03.mp3
└── cover.jpgKeeping one book per folder helps Audiobookshelf identify the files correctly. It also makes the collection understandable without requiring the application's database.
If Audiobookshelf disappeared tomorrow, I would still have a directory of playable files arranged by book.
Audiobookshelf as the front door
Audiobookshelf is the main interface I use for the collection.
Despite the name, it can manage more than audiobooks. It has basic support for EPUB, PDF, CBR, CBZ, AZW3, and MOBI files, so I created three libraries:
AudioBooks -> /books/media/audiobooks
Books -> /books/media/books
Comics -> /books/media/comicsThe audiobook library uses Audible as its metadata provider. That usually gives me the correct title, author, narrator, description, cover, and series information.
Audiobookshelf also tracks listening progress. I can stop halfway through a chapter on my iPhone and continue later on my iPad without finding my position again.
At the time I inspected the live database, Audiobookshelf showed 315 audiobooks, 66 books, and 215 comics. None of those entries were marked missing or invalid.
Audiobookshelf's ebook reader is not as elaborate as a dedicated ebook platform, and its own documentation describes ebook support as basic. That is fine for my setup. I mainly want one reliable interface that can expose all three libraries without taking control of the files away from me.
Listening with AudioBooth
I use AudioBooth on both my iPhone and iPad.
AudioBooth is an iOS client for Audiobookshelf. It connects to my server and gives me the mobile experience I would expect from a commercial audiobook application, including browsing, playback, offline downloads, and progress tracking.
The difference is that the server and files are mine.
Audible
-> Libation
-> NAS
-> Audiobookshelf
-> AudioBooth
-> iPhone or iPadThis is the part of the system I use most often. The server history reflects that too: AudioBooth accounts for nearly all recent audiobook playback.
The iPhone is my normal listening device because it is always with me. The iPad uses the same library and becomes useful when I am already reading or working on it.
Ebooks
The ebook library is less uniform than the audiobook collection. It currently contains EPUB, PDF, MOBI, AZW3, and a handful of older or miscellaneous formats.
EPUB is the format I would prefer to standardize on where practical, but I do not convert files just to make the extension list cleaner. If a PDF is supposed to have a fixed layout, turning it into a poorly formatted EPUB would not improve anything.
Audiobookshelf can display the supported formats in the same interface as my audiobooks. BookOrbit also indexes the directory and provides a more book-focused view of the collection.
I currently read these books on my iPhone and iPad. The iPad is better for longer reading sessions, while the phone is useful when it is the only device nearby.
An e-ink device is the next step, but I will come back to that later.
Comics
The comic library is the most consistent part of my collection. It currently contains 215 comics, primarily stored as CBZ files. Each comic normally has a cover image and metadata file stored alongside it.
The directory structure is deeper than the audiobook library because comics are usually organized by series and volume:
comics/
├── Series Name/
│ ├── Volume 01/
│ │ ├── Volume 01.cbz
│ │ ├── cover.jpg
│ │ └── metadata.json
│ └── Volume 02/
│ ├── Volume 02.cbz
│ ├── cover.jpg
│ └── metadata.json
└── Another Series/
└── ...Both Audiobookshelf and BookOrbit scan the same comic directory on my NAS. Audiobookshelf gives me a basic comic reader and remembers my reading progress, while BookOrbit provides better tools for organizing the collection and correcting metadata.
I read comics on my iPhone and iPad. The phone works when it is the only device I have nearby, but the iPad is a much better fit for full comic pages. The larger screen means less zooming and makes the experience feel closer to reading a physical copy.
For now, CBZ has become the practical standard for my collection. It is widely supported, easy to inspect, and does not lock the comic to a particular application.
Where BookOrbit fits
BookOrbit overlaps with Audiobookshelf, but it approaches the collection from a different direction.
Audiobookshelf is excellent at audiobook playback and provides a convenient shared interface. BookOrbit is closer to a general reading and library-management platform.
My BookOrbit installation has three separate libraries:
Audiobooks -> /audiobooks
Books -> /books
Comics -> /comicsEach library has its own allowed formats:
Audiobooks: M4B, MP3, FLAC, OPUS
Books: EPUB, KEPUB, PDF, MOBI, AZW3, AZW, FB2
Comics: CBZ, CBR, CB7BookOrbit can gather metadata from multiple providers, manage covers and series, expose an OPDS catalog, and synchronize with other reading platforms.
Metadata accuracy is important to me. A library application can save a lot of work when it identifies something correctly, but a confident wrong match can create an even larger mess.
Because of that, I do not enable every automatic write-back feature just because it exists. BookOrbit can rename files and write metadata into supported formats, but I keep most write operations disabled and review changes that could affect the actual media.
The database can be rebuilt from the folders if necessary. Incorrectly renamed or modified source files are harder to unwind.
Why I run both BookOrbit and Audiobookshelf
Running two applications against the same collection might seem redundant. It is, to some extent.
I keep both because their strengths are different:
- Audiobookshelf is the better audiobook server for my current use.
- AudioBooth gives me a good iOS listening experience.
- Audiobookshelf puts all three media types in one familiar interface.
- BookOrbit has stronger general library and metadata features.
- BookOrbit gives me a path toward KOReader and e-ink devices.
- Both applications can operate on the same files without requiring duplicate media libraries.
I am not interested in forcing one application to do everything merely for the sake of having one application.
Self-hosting often involves some overlap. The important question is whether that overlap creates confusion or gives each tool a clear job. In this case, I can keep Audiobookshelf as the front door while experimenting with BookOrbit's broader reading features.
The Docker layout
The real infrastructure paths, addresses, and domain names are intentionally omitted, but the relevant Audiobookshelf configuration looks like this:
services:
audiobookshelf:
image: ghcr.io/advplyr/audiobookshelf:latest
container_name: audiobookshelf
restart: unless-stopped
ports:
- "13378:80"
volumes:
- ./audiobookshelf/config:/config
- ./audiobookshelf/metadata:/metadata
- /srv/media/audiobooks:/books/media/audiobooks
- /srv/media/books:/books/media/books
- /srv/media/comics:/books/media/comics
environment:
- TZ=America/New_YorkThere are two persistent application directories. /config contains Audiobookshelf's database and configuration, while /metadata contains covers, metadata, backups, and other application-managed information.
BookOrbit uses shorter internal paths:
services:
bookorbit:
image: ghcr.io/bookorbit/bookorbit:latest
container_name: bookorbit
restart: unless-stopped
volumes:
- /srv/media/audiobooks:/audiobooks
- /srv/media/books:/books
- /srv/media/comics:/comics
- ./bookorbit/data:/dataBookOrbit also uses a PostgreSQL database. Its application data and database persist separately from the media.
Host or NAS path Audiobookshelf path BookOrbit path
/srv/media/audiobooks -> /books/media/audiobooks -> /audiobooks
/srv/media/books -> /books/media/books -> /books
/srv/media/comics -> /books/media/comics -> /comicsThere is no requirement for the internal paths to match. Each application only needs a stable path that corresponds with the library configured in its interface.
Storage and persistence
The NAS is the source of truth for the media.
The Docker host stores the application configuration, but it does not need its own copy of every audiobook, ebook, and comic. The NAS folders are mounted into the host and then passed into the containers.
This means recreating a container does not delete the library, both applications see the same files, and the media is not trapped inside Docker volumes. I can inspect and organize the files without either application, and another application could use the same library later.
The application databases still matter. They contain users, reading progress, metadata decisions, settings, and other information that cannot always be recovered by scanning the media folders again. Those directories need to be backed up along with the books.
The goal is not to pretend the database is disposable. It is to make sure a database failure does not also destroy the books.
The jailbroken Kindle plan
BookOrbit supports Kobo, KOReader, OPDS, Hardcover, StoryGraph, and Readwise integrations. I am not currently using any of them.
My next project is a jailbroken Kindle with KOReader installed.
The plan is to connect KOReader directly to BookOrbit. BookOrbit supports KOReader library access, progress synchronization, and annotation synchronization. In theory, this will let me browse the self-hosted collection, download a book to the Kindle, and keep my reading position synchronized.
NAS book library
|
v
BookOrbit
|
v
KOReader
|
v
Jailbroken KindleThat will give the ebook side of the setup a proper e-ink reader instead of relying entirely on my iPhone and iPad.
I am deliberately describing this as the plan rather than a finished feature. There is a difference between an integration appearing in a feature list and living with it every day. Once I have the Kindle connected and have used synchronization long enough to trust it, that setup will deserve its own post.
What I would change
The setup works, but it is not finished.
The ebook library still contains more formats than I would choose if I were starting from scratch. Some metadata requires manual cleanup. Audiobookshelf and BookOrbit overlap, and I am still deciding which application should be responsible for each part of the workflow.
I also want a clearer intake process for new ebooks and comics. BookOrbit includes a Book Dock feature for importing files, gathering metadata, and placing them into the correct library. My existing collection largely predates that workflow, so I have not committed to using it as the only entry point.
For now, I value predictability over full automation. Files enter a known directory, the applications scan them, and I review questionable metadata instead of allowing a chain of tools to rename everything automatically.
Was it worth it?
For me, yes.
I traded monthly software dependence for hardware and maintenance that I control. That is not the right trade for everyone. A hosted service is easier, and self-hosting does not make storage failures or metadata problems disappear.
What it gives me is control over the system surrounding my collection.
The audiobooks are playable files on my NAS. The ebooks and comics are readable without depending on a single storefront. I can replace AudioBooth, Audiobookshelf, or BookOrbit without rebuilding the media collection from nothing.
The applications are useful, but the files come first.
That is the part of self-hosting I care about most.
