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
  • operator confirmed it is still needed, so it should be preserved during cleanup and only rehomed deliberately later
• 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
  • operator confirmed Technitium covers the intended DNS role, so these should be treated as removable at the next cleanup window
• 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

Resolved operator decisions

Resolved on 2026-05-25:

1. No app should deliberately remain on Serenity once PD owns the disks locally.
2. Technitium covers the desired DNS role; the legacy Serenity Pi-hole stack should be treated as removable.
3. Newt on Serenity is still needed and should not be treated as cleanup.
4. GameVault and RomM should migrate rather than be pruned.
5. End-state remains:
   • move qbit + ARR family to PD after storage cutover
   • leave no intentional production app role on Serenity
   • retire Serenity entirely

Remaining verification questions

• Confirm whether anything beyond GameVault still depends on postgresql15.
• Confirm whether anything beyond RomM still depends on MariaDB-Official.
• Is /mnt/user/appdate/reranker intentional, or a typo that should be corrected before migration?
• When Pangolin API write auth is available again, rewrite Serenity target health-check hostnames away from stale 10.5.1.5 so the runtime alias can be removed cleanly.

Pangolin / Newt live remediation status

Live verification on 2026-05-25 showed Serenity Newt still probing stale pre-renumbering health-check URLs like http://10.5.1.5:8787/ even though the Pangolin target objects already showed ip=localhost or 10.5.30.5 for those resources.

Affected target IDs observed live:

• 15 (autobrr)
• 20 (notifiarr)
• 25 (readarr)
• 29 (wizarr)
• 56 (readarr-epub)
• 57 (sonarr-anime)
• 58 (romm)
• 69 (gamevault)

Diagnostic probe performed live on Serenity:

• temporarily added 10.5.1.5/32 to br0
• this immediately restored health for several targets, proving the stale hcHostname diagnosis

However, the old 10.5.1.5 address is no longer allowed on that VLAN, so the alias was removed again.

Verification after removal:

• ip addr del 10.5.1.5/32 dev br0
• Newt immediately resumed failures such as:
  • target 56 -> http://10.5.1.5:8788/
  • target 57 -> http://10.5.1.5:8990/
  • target 15 -> http://10.5.1.5:7474/
  • target 25 -> http://10.5.1.5:8787/

Interpretation:

• the alias was useful as a proof-of-cause test only
• it is not an acceptable steady-state fix here
• the real remaining task is to authoritatively rewrite the stale Pangolin hcHostname values away from 10.5.1.5

Database dependency findings

Live inspection of container environments currently points to:

• GameVault -> local postgresql15
  • DB_HOST=10.5.30.5
  • DB_PORT=5432
• RomM -> local MariaDB-Official
  • DB_HOST=10.5.30.5
  • DB_PORT=3306

No immediate database dependency was surfaced from the quick live environment check for:

• Wizarr
• Shelfmark
• Notifiarr

Operational implication:

• postgresql15 should currently be treated as a GameVault dependency until proven otherwise.
• MariaDB-Official should currently be treated as a RomM dependency until proven otherwise.
• those databases can likely retire once their dependent apps are migrated to PD and verified there.
• the legacy Pi-hole containers can be scheduled for removal at the next cleanup window.