Every template in the PodWarden catalog used to declare its storage intent at the stack level — useful, but coarse. A media server might mount /config, /cache, /media, and /transcodes: four volumes with completely different needs, and the catalog had one label for the whole thing. Backup defaults, storage-class picks, and migration plans all had to fall back on filename heuristics or ask the operator.
This week, that changed. 2,168 templates in the catalog now carry a per-volume intent map: each mount is independently classified into one of seven buckets.
Distribution across the catalog
| Intent | Volumes | What it tells us |
| ---------- | ------: | -------------------------------------- |
| data | 1,521 | App state worth backing up |
| config | 1,356 | Small, mutable settings dirs |
| media | 452 | Read-heavy archive content |
| cache | 215 | Scratch — safe to drop |
| db | 176 | Needs pre-snapshot quiesce |
| archive | 43 | Cold-tier, low-cadence |
| inbox | 38 | Spool / dropbox queues |
What this changes when you deploy a stack
- Backup policies are now per-volume. When you add a Jellyfin stack, PodWarden recommends snapshotting
/configand the library DB, and quietly leaves/cacheand/transcodesalone. No more dialog asking the same "do you want to back up/cache?" question for every media stack you install. - Storage classes follow intent. Clusters with both fast-SSD and archive-tier pools can route per-volume: the database mount lands on fast SSD, the media mount on the archive pool, all from the same template.
- Migrations get a fast path. When you move a stack between hosts, volumes marked
cachecan be dropped instead of copied. For some stacks this is the difference between a 4-hour migration and a 4-minute one.
How the classification was built
The classifier ran across 3,801 distinct volumes. Of those, 3,742 went through a language-model pipeline that read each template's compose source, mount path, and surrounding context to pick a bucket. The remaining 59 were resolved by deterministic safety rules — anything mounting /var/run/docker.sock, /proc, /sys, or a host device path is permanently tagged devices and never asked the model. Those overrides survive any future re-classification.
The model phase finished with a 0.7% error rate (26 individual volumes that failed to classify cleanly), well inside the 5% acceptance threshold. Volumes that erred stay un-classified and fall back to filename heuristics until the next refresh — no row was corrupted.
What you need to do
Nothing. If you maintain templates in the catalog, the intent column is populated for you. If you build against the MCP API, the volume_intents field is now in every template response and indexes per-volume by container-relative mount path.
If you spot a classification that's clearly wrong, the field is editable from the catalog admin UI — and per-template overrides survive the next refresh cycle.