truenas-stacks/docs/planning/SERENITY_DOCKER_AUDIT.md

Serenity Docker Audit

Status: live-audited baseline for cleanup and migration planning.

Last live verification: 2026-05-25

Access path used

Direct SSH from this session to root@10.5.30.5 failed with Permission denied. Live audit succeeded by hopping through PD:

• ssh pd
• then ssh -i /home/truenas_admin/.ssh/serenity_backup_ed25519 root@10.5.30.5

That means the inventory below is grounded in the current live runtime, but through PD's trusted Serenity backup key rather than direct local SSH.

What is currently running on Serenity

Keep for now until PD storage ownership changes

These are the containers whose current placement still makes operational sense because Serenity owns the active media/torrent locality today.

• qbit
• GluetunVPN
• qbit_manage
• prowlarr
• sonarr
• sonarr-anime
• radarr
• lidarr
• readarr
• readarr-epub
• bazarr
• autobrr
• unpackerr
• Notifiarr
• shelfmark

Common pattern observed from live mounts:

• these stacks are bound heavily to /mnt/user/data
• torrent state and backup artifacts live under Serenity-owned paths like /mnt/user/data/torrents, /mnt/user/data/BT_backup, and appdata under /mnt/user/appdata/*
• current path locality still argues for keeping them on Serenity until PD directly owns the disks and final media paths

Keep temporarily, but plan to move or collapse later

These are live today, but they are not good long-term reasons to keep Serenity alive after PD is rebuilt.

• reranker
  • currently on Serenity because CPU-only TEI was moved off PD
  • planned long-term home: PD if PD remains the AI control-plane/core host
• technitium-dns-pilot
  • current backup Technitium node on Serenity (10.5.30.10)
  • long-term: keep at least one off-PD backup resolver, but that does not have to remain on Serenity forever
• Newt
  • live on Serenity now, but docs only call out PD and NOMAD as the intended long-term Pangolin/Newt exposure lane
  • verify whether this agent is still needed before keeping it
• Hawser
  • helper/observability tooling, not a reason to preserve Serenity as a host role
• netdata
  • useful while Serenity remains live, not a reason to keep Serenity permanently
• GameVault
• romm
• Wizarr
  • these are normal app workloads, not storage-appliance-only workloads
  • long-term candidates for PD once the storage and app-host migration is ready

Retire candidates

These should be treated as cleanup targets unless a specific live dependency is rediscovered.

• Unraid-Cloudflared-Tunnel
  • already documented as dead/stale in repo docs
  • should be removed after one final dependency check
• binhex-official-pihole
• pihole-serenity
• unbound-pihole-serenity
• keepalived-pihole-serenity
  • these are legacy DNS/HA remnants now that Technitium is the active resolver strategy
  • repo docs now describe the Technitium trio as the active DHCP-advertised internal DNS path
  • unless some forgotten client or admin workflow still depends on them, these should be drained and removed
• postgresql15
• MariaDB-Official
  • both are live, but they are suspicious because current docs position PD as the shared database home
  • do not delete blindly; first identify whether any Serenity-only apps still depend on them
  • treat them as consolidation candidates, not permanent Serenity residents

Not-running / stale containers seen in docker ps -a

These did not appear live and should be reviewed for deletion after confirming their data is not needed.

Created only:

• calibre-web
• SuggestArr
• Cleanuparr
• calibre
• agregarr

Exited:

• Huntarr — exited 6 weeks ago
• omegabrr — exited 4 months ago

These are strong clutter candidates.

Live project roots observed

Compose Manager project roots found on Serenity:

• /boot/config/plugins/compose.manager/projects/pihole-ha
• /boot/config/plugins/compose.manager/projects/re-ranker

Direct compose file under appdata:

• /mnt/user/appdata/technitium-serenity/docker-compose.yaml

Operational implication:

• much of Serenity appears to be managed through Unraid Docker templates or ad-hoc container definitions, not a clean compose-per-stack layout
• cleanup work should expect drift between repo planning docs, backup stack snapshots, and the actual Unraid runtime inventory

Important live mount observations

Examples from the live container inspection:

• qbit binds /mnt/user/data -> /data
• qbit_manage binds /mnt/user/data, /mnt/user/data/BT_backup, and /mnt/user/appdata/qbit_manage
• shelfmark binds /mnt/user/data, /mnt/user/data/media/books/Audiobooks, /mnt/user/data/media/books/ingest, and /mnt/user/data/torrents
• most ARR-family services bind /mnt/user/data
• reranker binds /mnt/user/appdate/reranker -> /data

Notable typo/risk:

• reranker is mounted from /mnt/user/appdate/reranker (note appdate, not appdata)
• verify whether that path is intentional or an unnoticed typo before migration work touches it

Recommended cleanup order

Phase 1: remove obvious deadwood

1. verify no dependency remains on Unraid-Cloudflared-Tunnel
2. inspect whether the legacy Pi-hole stack still serves any traffic or admin purpose
3. remove stale created/exited containers that have no active role:
   • calibre-web
   • calibre
   • SuggestArr
   • Cleanuparr
   • agregarr
   • Huntarr
   • omegabrr

Phase 2: identify silent database dependencies

Before touching postgresql15 or MariaDB-Official, map which containers point at them.

Questions to answer:

• which apps on Serenity still use local Postgres?
• which apps on Serenity still use local MariaDB?
• are GameVault, RomM, Shelfmark, or Wizarr still backed by these local DBs?
• can any of those apps be moved to PD's shared DB stack cleanly?

Phase 3: preserve the only things that currently justify Serenity

Until PD owns the storage locally, keep the torrent/media-ingest locality group together:

• qBittorrent/VPN path
• ARR family
• qbit_manage
• autobrr
• unpackerr
• related helpers like Notifiarr and Shelfmark

Phase 4: cut over after PD storage migration

Once PD directly owns the relevant media/torrent datasets:

• move qbit + ARR locality to PD
• move reranker to PD if desired
• keep at least one off-PD Technitium node somewhere, preferably NOMAD if Serenity is retiring
• move or retire the miscellaneous app workloads still left on Serenity
• shut Serenity down as a permanent app host

Kanban-ready workstreams

Epic A — Serenity live inventory normalization

• capture docker ps, docker ps -a, mounts, ports, and database dependencies
• map every live container to one of: keep-now, move-to-PD, retire-now, or remove-as-stale
• verify whether any runtime definitions exist only in Unraid templates and not in repo-managed compose

Epic B — obvious dead container cleanup

• remove dead Cloudflared tunnel
• remove stale created/exited clutter containers
• verify and retire legacy Pi-hole/Keepalived/Unbound stack if no hidden dependency remains

Epic C — database dependency audit

• identify which Serenity apps use postgresql15
• identify which Serenity apps use MariaDB-Official
• decide whether those DBs move to PD shared databases or are retired with the apps

Epic D — torrent/media-locality preservation until PD cutover

• keep qbit/ARR stack stable on Serenity for now
• document exact media/torrent paths that must exist on PD before migration
• prevent premature moves that would recreate NFS-path weirdness

Epic E — final Serenity retirement

• move remaining wanted apps to PD or NOMAD
• preserve only the intended backup-DNS failure-domain role off PD
• decommission Serenity once no production path depends on it

Approval questions

1. Do you want to keep any of these as deliberate long-term Serenity residents, even after PD takes storage ownership?

   • GameVault
   • RomM
   • Wizarr
   • Shelfmark
   • Notifiarr

2. Is the legacy Pi-hole stack on Serenity allowed to be removed once we confirm Technitium covers all intended DNS duties?

3. Should Newt on Serenity be treated as a real long-term exposure path, or as cleanup unless we prove it is needed?

4. Are GameVault / RomM considered "nice to keep somewhere" apps that should migrate to PD, or are they candidates to prune?

5. Once PD owns the disks locally, is your preferred policy still:

   • move qbit + ARR family to PD
   • leave no intentional production app role on Serenity
   • retire Serenity entirely