Community reports from several-thousand-book libraries show slow UI behavior even on strong CPUs and plenty of RAM, making database/metadata/storage and application optimization more relevant than simply adding memory.
Collectors with thousands of audiobooks.Audiobookshelfのハードウェア要件：RAM、ストレージ、FFmpeg
Audiobookshelf の CPU、RAM、SQLite、ストレージ、FFmpeg、大規模ライブラリの要件を確認し、適した ZimaOS ハードウェアを選びましょう。
Audiobookshelf requirements at a glance
Audiobookshelf does not publish a numerical CPU or RAM minimum. Docker is the recommended installation method. The server stores its SQLite database under /config, metadata/covers/logs/backups under /metadata, and reads audiobook/podcast libraries from separate mounts. Most playback is lightweight; scanning and FFmpeg-based conversion/transcoding are the main compute bursts.
- CPU
- No numerical official minimum. Normal audiobook streaming is light; scans, metadata embedding, chapter tools, audio conversion and on-the-fly transcoding can use substantially more CPU.
- RAM
- No numerical official minimum. Large libraries can become database/UI performance workloads, but adding RAM alone does not guarantee faster browsing.
- Database
- Audiobookshelf stores the SQLite database under /config. Official docs explicitly say /config must stay on storage local to the server rather than a network filesystem.
- Metadata storage
- /metadata stores covers, author images, cache/streams, downloads, logs and backups, so SSD placement can improve library/UI responsiveness even when audio files remain on HDD/NAS storage.
- FFmpeg
- Audiobookshelf relies on FFmpeg/FFprobe for audio parsing and media tools. The current Docker image includes FFmpeg 8; codec support can still affect scan/transcode behavior.
- Best Zima starting point
- ZimaBoard 2 832 is a strong normal Audiobookshelf host. ZimaCube 2 becomes useful when the audiobook/podcast library itself needs multi-drive storage, not because audio streaming needs a powerful CPU.
From official requirements to the right setup
Audiobookshelf sizing separates lightweight streaming from database/metadata and FFmpeg work.
-
Official requirements
Keep /config on local server storage. The official Docker guide warns that putting the SQLite database on a remote/NAS filesystem can hurt performance and eventually cause corruption.
-
Confirm your needs
Place /metadata on responsive persistent storage when the library is large. Covers, author images, cache, streams, downloads, logs and backups are read more interactively than bulk audiobook media.
-
Leave room to grow
Estimate FFmpeg work separately. Directly supported playback is light, while merge-to-M4B, metadata embedding and codec transcoding consume CPU and temporary storage.
-
Run it on ZimaOS
Install Audiobookshelf from ZimaOS, run a representative full-library scan, browse cover-heavy views and test any conversion/transcoding workflow before deciding the server needs more RAM or CPU.
Check every playback client
- Total audiobook/podcast library size
- Number of books/items
- Local /config SQLite storage
- /metadata SSD placement
- Bulk media on HDD/NAS storage
- FFmpeg conversion/transcoding use
- Podcast auto-download volume
- Backup and restore capacity
Official minimum requirements
Audiobookshelf documents storage layout, Docker and FFmpeg dependencies but does not publish a universal CPU or RAM minimum.
Do not import Plex/Jellyfin video-server RAM or GPU guidance into Audiobookshelf. Audio serving is usually light, while local SQLite placement, metadata/covers and FFmpeg conversion are the more relevant constraints.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU | No numerical minimum published | CPU demand rises mainly during scans and FFmpeg media tools/transcoding. |
| RAM | No numerical minimum published | Large-library performance depends on more than memory alone. |
| Config/database | /config | Contains SQLite database and migrations; must not be hosted on a network filesystem. |
| Metadata | /metadata | Contains metadata, cover/author images, logs and backups. |
| Default Docker port example | 13378 | The official compose example maps 13378 to container port 80. |
| GPU | Not required | No dedicated-GPU requirement is documented. |
When to upgrade your hardware
Upgrade Audiobookshelf when library/database/metadata or media-tool work becomes the measured bottleneck.
A very large library makes browsing and cover loading slow
FFmpeg conversion or transcoding becomes frequent
Podcast downloads and media storage keep growing
Merging many files into M4B, embedding metadata or transcoding unsupported codecs creates sustained CPU and temporary-storage work that normal streaming does not.
Users actively converting or normalizing audiobook libraries.The database may stay small while audio files, covers, downloads and backups dominate disk capacity.
Large audiobook/podcast libraries and multi-user archives.Plan hardware growth with confidence
Scale Audiobookshelf by separating appdata/metadata from bulk media.
Keep /config local and fast
Audiobookshelf explicitly warns against network-mounted SQLite because of performance and corruption risk.
Use local eMMC/SSD/NVMe for /config rather than an NFS/SMB config path.Put metadata/covers on SSD
Cover-heavy browsing and cache/metadata access are latency-sensitive compared with sequential audiobook streaming.
Use SSD appdata while keeping the large media library on HDD if desired.Treat audio conversion as a batch CPU workload
Audiobookshelf includes tools to merge and edit audiobook media using FFmpeg. Schedule large conversion jobs when other server work is low.
A stronger CPU helps batch conversion more than extra RAM or a dedicated GPU.Use multi-drive storage when the library becomes the constraint
Audiobook and podcast files, downloads and backups can outgrow a compact server's attached storage long before the application process needs more compute.
ZimaCube is appropriate when storage capacity and backup growth are the real triggers.Can it run on ZimaOS?
Audiobookshelf is currently available in the ZimaOS App Store under Media.
Install Audiobookshelf from the ZimaOS App Store
Use the packaged audiobook/podcast server and keep appdata/metadata persistent.
Open Audiobookshelf in the ZimaOS App StoreKeep /config off network filesystems
The official Docker guide says the SQLite config path must be directly accessible on the Audiobookshelf server.
Read Audiobookshelf Docker storage guidanceAccount for FFmpeg and metadata paths
Current environment documentation defines FFmpeg/FFprobe and metadata/backups as explicit server paths/tools.
Read Audiobookshelf environment configurationChoose Zima hardware for Audiobookshelf
Audiobookshelf is generally a light media server. Storage layout and large-library metadata performance matter more than video-transcoding hardware.
Is this a normal audiobook server or a large multi-drive media archive?
Normal personal/family audiobook server
ZimaBoard 2 832 comfortably handles Audiobookshelf with local appdata and media storage.
- Normal Audiobookshelf serverZimaBoard 2 832
- Larger library / more media appsZimaBoard 2 1664
Large audiobook/podcast archive
Use ZimaCube when multi-drive media capacity and backups become the main requirement.
- Multi-drive audiobook serverZimaCube 2 Standard
- Larger media/conversion stackZimaCube 2 Pro
No fixed books-per-server, users or transcode count is guaranteed. File count, metadata, browser/client behavior, codec, conversion jobs, storage latency and network access all matter.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A personal/family Audiobookshelf server. | Streaming, library scans and occasional audio tools. |
|
Very large libraries can become app/database/UI bottlenecks independent of raw CPU/RAM. | Get Now |
| ZimaBoard 2 1664 | Audiobookshelf plus more media applications and heavier batch jobs. | Larger shared server headroom and more concurrent app workloads. |
|
16 GB is whole-server headroom, not an Audiobookshelf requirement. | Get Now |
| ZimaCube 2 Standard | A large multi-drive audiobook/podcast archive. | Audiobookshelf plus bulk media, downloads and backups. |
|
Choose it for storage capacity rather than audio streaming compute. | Get Now |
| ZimaCube 2 Pro | A larger all-in-one media server with frequent CPU-side conversion tasks. | More media apps, storage and faster batch FFmpeg work. |
|
Use Pro for the wider media/conversion workload, not ordinary audiobook streaming. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
FAQ topics follow query fan-out around RAM, cheap NAS hardware, large-library performance, SQLite placement, SSDs and FFmpeg conversion. Reddit is used for field experience, while official Audiobookshelf docs define storage and tool requirements.
How much RAM does Audiobookshelf need?
Audiobookshelf does not publish a RAM minimum. Normal audiobook streaming is lightweight, and large-library UI performance cannot be predicted from RAM alone.
Can Audiobookshelf run on a cheap NAS or Raspberry Pi-class server?
Yes for normal serving if Docker/platform support and storage are suitable. Community users commonly seek very low-power hosts because audio streaming itself is modest.
Why is Audiobookshelf slow with thousands of books even on a fast PC?
Community reports from roughly 6,000-book libraries show slow browsing even with i7-class CPUs, 32 GB RAM and SSDs. Large-library application/database/cover behavior can therefore dominate before hardware is exhausted.
Should Audiobookshelf /config be stored on my NAS share?
No if that means a network filesystem. The official Docker guide explicitly says /config contains SQLite and must be directly accessible on the same server, otherwise performance suffers and database corruption can occur.
Should /metadata be on SSD?
It is a good practical choice for large libraries because /metadata contains covers, author images, cache/streams, logs and backups. Bulk audiobook files can remain on slower high-capacity storage.
Does Audiobookshelf transcode audio?
It can use FFmpeg for parsing/media tools and some playback conversion. The current Docker build includes FFmpeg 8, but codec support still matters; xHE-AAC is a documented example.
Can ZimaBoard 2 832 run Audiobookshelf?
Yes. Its Intel N150 and 8 GB RAM provide ample headroom for a normal Audiobookshelf deployment; local appdata storage and library capacity are more important.
When is ZimaCube 2 worthwhile for Audiobookshelf?
When the audiobook/podcast library, downloads and backups require multi-drive storage, or when Audiobookshelf is one part of a larger media server. Audio streaming alone does not justify it.
What sources and further reading informed this Audiobookshelf hardware guide?
Audiobookshelf's official Docker and configuration docs define /config, /metadata, SQLite placement, backups and FFmpeg paths. The server FAQ documents codec/FFmpeg behavior. Reddit was used for query fan-out around large-library performance and cheap NAS hosts, while ZimaOS confirms the current Media app.
