Container Footprint Review

Last updated: 2026-06-14

This note records the current bias for VHNIC Docker architecture: avoid adding

more containers unless a separate container provides a clear operational,

security, or maintainability benefit. Consolidation is allowed when it reduces

complexity without making rollback, permissions, monitoring, or upgrades worse.

Current Bias

• Prefer improving existing stacks before creating new services.
• Prefer one project per functional area, not one project per experiment.
• Keep admin/automation tools internal-only unless there is a deliberate access

plan.

• Keep public exposure narrower than internal service count.
• Use monitoring to identify idle or noisy containers before consolidating.
• Do not combine containers just to reduce the visual count if it creates

tighter coupling, broader filesystem permissions, or worse failure isolation.

Book And Audiobook Stack Assessment

The current separation is defensible because the remaining apps have different

trust levels:

• Audiobookshelf and Kavita are reader-facing.
• Mylar3 is automation/admin-facing.
• Kavita intentionally gets read-only media mounts; Mylar3 may need writable

comic/manhwa mounts if it is ever used.

The likely footprint win is not combining these into one custom container. The

safer option is to retire unused management tools after a trial period:

• ReadAIrr was approved for retirement on 2026-06-14 and should be removed from

runtime and monitoring.

• If Mylar3 is not useful for comics/manhwa, stop or remove Mylar3 after exact

approval.

• Keep Audiobookshelf and Kavita if they become the actual reader/player apps.

Other Consolidation Candidates

Monitoring Expectations

The local observability config should monitor the newer book/reading/portal

services at two levels:

• HTTP reachability through Blackbox Exporter for Homepage, Homepage Docs,

Audiobookshelf, Kavita, and Mylar3.

• Expected-container presence/restart checks through cAdvisor for homepage,

homepage-docs, audiobookshelf, kavita, and mylar3.

If the live monitoring stack has not been synced/reloaded since 2026-06-14,

check the tracked Prometheus config before assuming these probes and alerts are

live.

Practical Review Process

Before adding another container:

1. Check whether an existing app already solves the need.

2. Decide whether the new app is reader-facing, admin-facing, or public-facing.

3. Identify appdata, media mounts, secrets, and required network exposure.

4. Decide whether the app can be a short-lived trial instead of always-on.

5. Add service and expected-container monitoring before treating it as durable.

6. Add a rollback/removal note so retirement is easy if the tool is not useful.

Before consolidating or removing a container:

1. Confirm whether it is actually running and whether anyone uses it.

2. Check cAdvisor/Grafana for CPU, memory, restarts, and uptime.

3. Confirm whether it owns unique appdata or secrets.

4. Confirm whether other services depend on it.

5. Prefer stop/disable first, then remove only after an observation period and

exact-path/object approval.

Current Recommendation

Do not create additional book/audiobook containers right now. Stabilize the

current Audiobookshelf, Kavita, and Mylar3 setup, and keep audiobook ingestion

manual through the Need_Processing workflow unless a replacement automation

tool clearly earns its cost.

For media automation, prefer better use of the existing Arr stack before adding

new containers. Any new tool should either replace a current manual workflow or

provide a clearly monitored capability. The next likely wins are controlled

configuration improvements inside Sonarr/Radarr/Lidarr/Prowlarr/Seerr, not

another always-on service. Bazarr was retired on 2026-06-14 after repeated

noise and no clear operational value.

2026-06-07 Live Footprint Snapshot

Read-only Prometheus/cAdvisor review showed 35 named live containers. The

largest working-set memory users were:

The six lightweight Python exporter/bridge containers together used about

89 MB working set:

No named containers showed restarts in the previous 24 hours at the time of the

snapshot. This means exporter consolidation is not likely to materially reduce

NAS resource pressure right now. If consolidation is pursued, it should be for

repository/deployment simplicity rather than CPU or memory savings.

Exporter consolidation notes:

• tdarr-exporter, tautulli-exporter, unifi-exporter,

synology-log-exporter, and media-pipeline-exporter could technically be

combined into one custom multi-exporter image or process supervisor.

• Keeping them separate preserves clearer failure isolation, narrower mounts,

simpler per-exporter logs, and easier targeted restarts.

• Combining them would merge secrets/mount permissions and make a bug in one

exporter capable of taking down all custom exporter metrics.

• The best near-term compromise is to keep exporters separate, but avoid adding

more one-off exporter containers unless the signal is important enough for a

dashboard or alert.

Component	Current Role	Consolidation View
audiobookshelf	User-facing audiobook library/player	Keep separate. It is the app users care about, has its own metadata/appdata, and may later be public through Caddy for ShelfPlayer.
readairr	Retired audiobook/ebook automation trial	Remove from runtime and monitoring. The tool created repeated high-IO scans and bad imports without enough value.
readairr-postgres	Retired ReadAIrr database	Remove with ReadAIrr; no other service should depend on it.
kavita	Ebook/comic/manhwa reader with read-only media mounts	Keep separate. It is the reader UI and has a safer read-only media posture.
mylar3	Comic/manhwa management candidate	Candidate to disable/remove later if unused. Do not connect indexers/download clients until the workflow is explicitly reviewed.
Area	Candidate	Notes
Historical compose folders	dispatcharr-compose, homarr-compose, old standalone Seerr/NZBGet/Tautulli folders	Keep as history unless the user approves exact cleanup. They should not run or create monitoring noise.
Homepage Docs	homepage-docs companion nginx container	Candidate to combine only if Homepage can reliably serve generated docs itself. Current nginx sidecar is simple, read-only, and low risk.
Observability exporters	Tdarr, Tautulli, UniFi, Synology log, media pipeline exporters	Combining into a single exporter image would reduce container count but increase blast radius and deployment friction. Keep separate unless exporter overhead becomes a measured problem.
Reverse proxy	Caddy	Keep separate. It is the public edge and should stay isolated from app containers.
qBittorrent/Gluetun	VPN project	Keep separate as designed. qBittorrent's network namespace depends on Gluetun; this separation is security-relevant.
Recyclarr	Manual/reference tool	Already removed from always-on service expectations. Keep manual-only unless explicitly reactivated.
Container	Approx Working Set	Interpretation
plex	7.7 GB	Dominant load; not a consolidation candidate.
tdarr	3.4 GB	Expected heavy media-processing service.
qbittorrent	1.0 GB	Meaningful but tied to Gluetun/VPN posture.
nzbhydra2	408 MB	Existing meta-search service; not related to the new book containers.
seerr	301 MB	Request app.
radarr	266 MB	Core media-management app.
tautulli	242 MB	Plex observability/history.
sonarr	213 MB	Core media-management app.
kavita	205 MB	Reader app; reasonable for a durable reader.
Container	Approx Working Set	Approx CPU Cores
tdarr-exporter	27 MB	0.031
tautulli-exporter	18 MB	0.003
media-pipeline-exporter	17 MB	0.003
unifi-exporter	12 MB	0.001
synology-log-exporter	10 MB	0.007
discord-alert-bridge	5 MB	0.000