Splitting App Storage from Bulk Storage on a NAS-plus-Mini-PC Homelab

The NAS-plus-mini-PC homelab is a great pairing: the mini PC runs the containers, the NAS holds the terabytes. It goes wrong when the split between them is never actually decided, and Docker volumes land wherever the first tutorial put them. A month later there's a SQLite database living on an NFS share, a docker-compose.yml that assumes a path that only exists at 2am when the NAS is awake, and a Jellyfin library that's somehow both places. Decide the split before the stack grows and none of that happens.

Two kinds of storage, two very different needs

• App state — databases, app config, indexes, lock files. Small, latency-sensitive, and intolerant of the disk disappearing. Wants fast local SSD and a filesystem that never goes away mid-write.
• Bulk data — media, photos, backups, archives. Large, throughput-oriented, fine over the network, tolerant of slightly higher latency.

Almost every homelab storage problem comes from putting app state on bulk storage. NFS latency, a sleeping NAS disk, or a dropped mount turns into a corrupted database — exactly the failure mode covered in USB-DAS storage guardrails.

The split: SSD for state, NAS for bulk

• Databases and app config → the mini PC's internal SSD/NVMe. Postgres, MariaDB, SQLite, and each app's config directory live local. Fast, always-present, journaled.
• Media and large files → the NAS. Mount the share read-write for the media apps that need it, and keep it out of the database path entirely.

Concretely, for a media app: the library files live on the NAS share, but the app's database and metadata live on the SSD. That one separation is the difference between "the NAS hiccuped and Jellyfin paused" and "the NAS hiccuped and the database is corrupt."

Make the mounts explicit and resilient

• Mount NAS shares by a stable name with nofail so a missing NAS doesn't wedge boot.
• Set soft/timeout options on NFS so an unreachable NAS errors instead of hanging containers forever.
• In Compose, map the SSD path and the NAS path as distinct named volumes/binds — never a single tree that straddles both.

Watch the cross-cutting effects

Once several apps share one mini PC and one NAS, they compete. Keep app ports and resources from colliding (see multi-app VPS port collisions), and back up the SSD app state off the box — the NAS holding your media is not a backup of the database that indexes it.

Quick layout

Data	Lives on	Why
Postgres/MariaDB/SQLite	mini-PC SSD	latency + always-present
App config / index	mini-PC SSD	small, must stay consistent
Media / photos / archives	NAS	large, throughput, network-tolerant
Backups of app state	off-box / NAS and off-site	survive loss of either box

Takeaway

Decide it once: state on the SSD, bulk on the NAS, mounts explicit and nofail, app-state backups off the box. Make that call before the first stateful container and the NAS-plus-mini-PC homelab stays fast, boots cleanly, and survives the inevitable NAS nap.