# 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