Future Changes Backlog

Last updated: 2026-06-22

This file tracks recommended changes and investigations that were discussed but

not fully implemented. It is intentionally conservative: items here should be

reviewed before action, especially anything that affects DNS, storage,

firewalls, exposed services, or deletion.

Highest Priority

Security-First Operating Principle

Status: standing rule for future VHNIC changes.

Security, anti-intrusion, and anti-tracking are now first-class project goals,

not optional cleanup items. Future work should prefer the safer design even if

it takes a little more setup.

Standing rules:

• Minimize public exposure. Every public port forward should have a named

purpose, owner, and review date.

• Prefer reverse proxy plus explicit routes over direct app-port exposure.
• Do not publicly expose administrative apps such as DSM, Sonarr, Radarr,

Grafana, Homepage, Pi-hole, NZBHydra2, NZBGet, qBittorrent, Tdarr, or

Homebridge without a separate VPN or identity/2FA layer.

• Prefer least-privilege service accounts and scoped helpers over broad sudo or

arbitrary remote shell access.

• Keep secrets out of tracked project files. Store credentials in local

.secrets paths or remote secrets directories with restricted permissions.

• Keep Pi-hole as the primary privacy/ad/tracker DNS layer unless there is a

deliberate migration plan.

• Treat new containers, new port forwards, new DNS records, and new UniFi

clients as security-relevant changes.

• Prefer notification-only or controlled image updates over broad automatic

container updates.

• Keep appdata backups, restore notes, and rollback paths current before making

major service changes.

Near-term hardening priorities:

1. Build monitoring/reporting for public port-forward drift, new UniFi clients,

SSH failed-login spikes, unexpected Docker containers/images, and DNS record

changes. Initial expected-state plan:

security/SECURITY_POSTURE_MONITORING_PLAN.md.

2. Remove Plex Test and disable Minecraft public forwards. Approved helper:

tools/unifi/Set-UnifiApprovedPortForwards.ps1.

3. Add an identity-aware access layer, such as Authelia, Authentik, or VPN-first

access, before exposing any internal portal or admin dashboard.

4. Consider disabling Synology SSH password authentication after verifying

key-based access and emergency access paths.

5. Review and document all privileged helper scripts and NOPASSWD entries.

6. Enable DNSSEC for ravick5.com after coordinating the Google Cloud DNS

signing step with registrar DS-record publication.

7. Continue tuning Pi-hole lists and local DNS with a privacy-first bias, while

avoiding overblocking that makes troubleshooting chaotic.

Observability Next Monitoring Additions

Status: partly deployed; remaining work is targeted hardening/coverage.

• Current Prometheus/Grafana coverage already includes service reachability,

container presence/restarts, container resource usage, Synology filesystem

usage, md/RAID state, Btrfs error counters, disk busy/latency, Plex/Tautulli,

Tdarr, UniFi, and Pi-hole DNS probe health.

• Since the May 30 Synology hang, a narrow read-only Synology log exporter has

been deployed to watch DSM backend timeouts, Btrfs known/unknown block

errors, core dump signals, and storage timeout/reset language.

• The most useful next monitoring additions are now:
• a narrow read-only Synology SMART/scrub-age exporter or textfile collector,
• backup freshness panels for Pi-hole/appdata/project reports,
• Windows desktop/Tdarr node health,
• deeper Pi-hole query/block metrics if API credentials are later approved.
• security posture monitoring for public port-forward changes, new UniFi

clients, SSH failed-login spikes, and unexpected Docker container/image

changes.

• Do not build this as arbitrary remote command execution. Use scoped helpers

with explicit read-only commands and no repair/delete capability.

• Prometheus retention remains time-based at 30 days with no size cap. Recheck

footprint around 2026-06-28 before deciding whether to add a retention size

limit.

Reference:

synology/docker/projects/observability-compose/CURRENT_STATE.md
synology/docker/projects/observability-compose/IMPROVEMENT_PLAN.md

Security Hardening Follow-Up

Status: reviewed 2026-06-01; no breach evidence found, hardening remains.

• A read-only breach/security assessment was performed on 2026-06-01. No clear

evidence of compromise was found across the reviewed Synology, Docker, UniFi,

Pi-hole, and Google Cloud DNS evidence.

• DNSSEC was assessed on 2026-06-13. Google Cloud DNS is authoritative for

ravick5.com, but the public zone is currently unsigned

(dnssecConfig.state: off). See google-cloud-dns/DNSSEC_PLAN.md before

enabling it.

• Keep these as planned hardening items, not emergency response items:
• label generic UniFi clients and identify IoT devices with weak names,
• keep direct qBittorrent and direct Seerr/Overseerr forwards disabled,
• review whether Plex Test and Minecraft public forwards are still needed,
• consider disabling Synology SSH password auth after verifying key-based and

emergency access paths,

• enable DNSSEC for ravick5.com as a coordinated Cloud DNS plus registrar

DS-record change,

• add monitoring/reporting for public port-forward drift, new UniFi clients,

unexpected Docker container/image changes, and SSH failed-login spikes.

Reference:

security/breach-assessment-20260601.md
synology/security/Capture-SynologySecurityAudit.ps1

Internal Friendly Names / Reverse Proxy

Status: design clarified; implementation should not be DNS-only.

The environment should eventually support internal service names instead of

requiring LAN IP plus port for every app. This would make day-to-day use cleaner

and would also make Homepage/Grafana links easier to maintain.

Recommended shape:

• Use split-horizon/internal DNS through Pi-hole or UniFi so names resolve only

on the LAN.

• Prefer a dedicated internal subdomain such as home.ravick5.com,

lan.ravick5.com, or internal.ravick5.com.

• Point friendly names such as sonarr.home.ravick5.com,

radarr.home.ravick5.com, grafana.home.ravick5.com, and

homepage.home.ravick5.com to the reverse proxy host.

• Use Caddy as the internal reverse proxy unless there is a strong reason to

split this onto a Pi.

• Keep public and internal routes separate. Internal app names should not imply

public exposure.

• Decide TLS strategy before implementation:
• HTTP-only on trusted LAN is simplest but less polished.
• Public DNS challenge certificates can give trusted HTTPS without exposing

the apps.

• Caddy internal CA can work, but clients must trust the internal CA or they

will see certificate warnings.

• Do not expose administrative tools like Sonarr, Radarr, Grafana,

Homepage, Pi-hole, or Synology DSM publicly without a separate identity/2FA

layer such as Authelia, Authentik, or VPN-first access.

This is related to, but separate from, the current public Caddy route for Seerr.

Important 2026-06-13 finding: current Caddy uses Synology host ports 8088

and 8443 because DSM owns 80 and 443. DNS cannot encode ports, so simply

adding Pi-hole records for *.home.ravick5.com -> 10.0.0.119 would not provide

clean no-port URLs. Use a dedicated internal proxy IP, a separate proxy host, or

Synology's built-in reverse proxy.

Runbook:

synology/docker/projects/reverse-proxy-compose/INTERNAL_FRIENDLY_NAMES_PLAN.md

Tdarr Post-Completion Follow-Up And Anime Prep

Status: original broad rollout complete; evening queue and Anime prep remain.

• Kids TV and Kids Movies completed cleanly on 2026-05-23 with zero current

file-level transcode errors and zero current health-check errors.

• Movies, TV Shows, and Reality were added and processed as the remaining broad

rollout targets.

• Reality was added on 2026-06-07 and needed a Reality-only legacy AVI repair

profile for 20 old Survivor AVI health-check failures.

• The 2026-06-10 capture showed the main rollout queue and errors at zero.
• The latest 2026-06-11 local capture shows 112 queued transcodes and 98

active jobs with 0 transcode errors and stable DB load. Treat these as the

current evening finish-out queue; recapture after it drains.

• Preferred next targets:

1. Recapture Tdarr progress and health after tonight's remaining queue finishes.

2. Review any residual non-HEVC legacy files surgically by library/codec.

3. Prepare an Anime-specific test profile, not a normal cloned rollout.

• Do not include Personal in any Tdarr workflow.
• Music and YouTube were checked separately on 2026-06-07. Music cleanup should

stay in Lidarr/Picard-style metadata hygiene rather than Tdarr compression.

YouTube had no obvious junk cleanup; compression or retention would be the

only meaningful space lever there.

Reference:

synology/docker/tdarr/README.md
synology/docker/tdarr/COMPLETION_MILESTONES.md
synology/docker/tdarr/NEXT_LIBRARY_ROLLOUT_PLAN.md
synology/docker/music/README.md
synology/docker/YOUTUBE_LIBRARY.md

Music Metadata Hygiene

Status: safe duplicate cleanup done; metadata cleanup remains manual/reviewed.

• On 2026-06-07, 117 exact duplicate copy-suffix music files and 12 clutter

files were moved to quarantine, not deleted.

• Quarantine path:

/volume1/data/media/_codex_quarantine/music-20260607-safe-duplicates

• Empty music folders were removed after the quarantine pass.
• Three suspicious exact-byte duplicate Lynyrd Skynyrd groups remain because

the filenames/titles differ. Review manually before any move/delete.

• Lidarr shows 425 track-file rows with AlbumId = 0; do not trigger broad

rename/retagging until those are understood.

• Future metadata cleanup should use a reviewed Lidarr/MusicBrainz Picard

workflow rather than blind embedded tag edits.

Reference:

synology/docker/music/README.md

Personal Media Protection

Status: hard rule.

• /volume1/data/media/personal contains irreplaceable family videos.
• Do not transcode, rename, move, delete, clean up, replace, or bulk modify it.
• Only read-only inventory or backup planning is allowed, and only if explicitly

requested.

• Future priority should be backup/preservation planning, not compression.

Reference:

synology/HANDOFF.md
synology/docker/tdarr/NEXT_LIBRARY_ROLLOUT_PLAN.md

Synology Volume 1 Btrfs Follow-Up

Status: active evacuation and rebuild planning item after Synology Support

identified likely memory-related bit flip corruption.

• md2 RAID6 repair/resync finished cleanly with all eight members present.
• Volume 1 Btrfs scrub/device counters remain at the known value:

35,311 checksum/corruption errors, 0 corrected.

• Verify the removed/replaced damaged media file is restored cleanly.
• Privileged read-only logical block path lookup was run on 2026-05-22:

btrfs inspect-internal logical-resolve 56885910093824 /volume1.

• Result: ERROR: logical ino ioctl: No such file or directory; no live file

path was identified for that logical block.

• Synology Support reviewed the NAS logs and reported thousands of bit flip

errors dating back to March 2026. They identified unsupported Crucial

CT16G4SFRA266.C8FF RAM as a likely contributor.

• The unsupported RAM has been removed.
• A 2026-06-14 Plex buffering/storage investigation found the same logical

block still logging Btrfs metadata errors, plus md2 self-heal retries that

sometimes ended in give up while DSM still reported the array active.

• Support-case bundle:

synology/support-cases/20260614-volume1-btrfs-md2/.

• A DX1222 was added and Volume 4 temp_media was created as a temporary

RAID 6/Btrfs landing zone.

• Active migration root: /volume4/migration-from-volume1.
• Active plan: synology/storage/VOLUME1_REBUILD_MIGRATION_PLAN.md.
• Near-term operating posture: finish the initial queue, run true-up passes,

stop write-heavy services for final true-up, validate the landing copy, then

remove/recreate Volume 1 only after explicit user approval.

• Do not run live Btrfs repair commands.
• Treat Volume 1 evacuation/recreate/restore planning as a realistic possible

outcome if Synology cannot provide a supported non-destructive repair path.

• Keep avoiding btrfs check --repair on the live filesystem.

Reference:

synology/storage/CURRENT_STATE.md
synology/HANDOFF.md

Synology Appdata Backup Plan

Status: planned, not fully implemented.

• Decide final appdata backup destination.
• Prefer a real backup target outside the same single failure domain:

external USB, another machine/NAS, or cloud/offsite.

• In the interim, a Synology-local backup is better than nothing but should not

be treated as disaster recovery.

• Include important appdata paths, especially Plex, Tdarr, Seerr, Sonarr,

Radarr, Lidarr, Prowlarr, NZBHydra2, qBittorrent, and Gluetun.

• Keep retention reasonable and avoid blind pruning/deletion without approval.

Reference:

synology/docker/BACKUP_STRATEGY.md

Second Windows Tdarr Node

Status: candidate reachable, not configured.

• Candidate host: 10.0.0.126.
• As of 2026-05-23:
• ping reachable,
• RDP 3389 reachable,
• SMB 445 reachable,
• SSH 22 not open.
• Next steps:
• RDP into the machine or enable a controlled remote shell path.
• Confirm hardware, especially NVIDIA GPU/NVENC availability.
• Install/configure Tdarr Node with a unique node name such as

VHNIC-Node-126.

• Start with 0 workers or very low workers until path translation and cache

behavior are verified.

Reference:

synology/docker/tdarr/native-worker/SECOND_WINDOWS_NODE.md

Public Exposure For Seerr

Status: Caddy reverse proxy project live for Seerr only.

• Overseerr was migrated to Seerr on 2026-05-24.
• Do not expose Seerr directly without reverse proxy hardening.
• Stage 1 location selected: Synology Docker, with Caddy runtime appdata on

/volume3/docker/reverse-proxy.

• DSM owns Synology host ports 80/443, so Caddy publishes on host ports

8088/8443.

• Local project source:

synology/docker/projects/reverse-proxy-compose.

• Remote project files were uploaded to:

/volume1/docker/projects/reverse-proxy-compose.

• Caddy is running on 8088/8443 and has a Let's Encrypt certificate for

overseerr.ravick5.com.

• UniFi forwards public 80 -> 10.0.0.119:8088 and public

443 -> 10.0.0.119:8443.

• Caddy upstream now points to seerr:5055.
• Seerr has applicationUrl set and trustProxy enabled.
• Seerr cacheImages remains disabled to avoid large disk use. Caddy handles

mixed-content warnings with:

Content-Security-Policy: upgrade-insecure-requests; block-all-mixed-content.

• Legacy overseerr container is stopped with restart policy disabled; appdata

and a timestamped migration backup are retained.

• Remaining hardening: test public login/request flow, then enable Seerr

csrfProtection if no proxy-header issues appear.

• Current public aliases intentionally route to Seerr through Caddy:
• overseerr.ravick5.com
• seerr.ravick5.com
• requests.ravick5.com
• The typo overserr.ravick5.com was removed from DNS and Caddy.
• Consider changing the UniFi HTTP/HTTPS forwards from TCP/UDP to TCP-only

unless HTTP/3/QUIC is intentionally desired later.

• Revisit Seerr applicationUrl, trustProxy, and csrfProtection.
• Current DNS uses explicit service records rather than a wildcard.

Reference:

synology/docker/REVERSE_PROXY_OVERSEERR_PLAN.md
synology/docker/OVERSEERR_REVIEW.md
synology/docker/projects/seerr-compose/README.md
google-cloud-dns/README.md

Homepage Remote Access Discussion

Status: discussion needed before any implementation.

• Homepage became the internal VHNIC portal on 2026-06-03 after replacing the

short-lived Homarr pilot.

• Current Homepage links intentionally point to LAN-only addresses such as

10.0.0.119, 10.0.0.195, 10.0.0.132, and 10.0.0.1.

• If Homepage is exposed publicly without a VPN or identity-aware access layer,

those internal links will not work from normal remote devices.

• Homepage also acts as a map of the environment, so exposing it increases the

value of a compromised account/session.

• Before implementation, decide between these access patterns:
• VPN/overlay access first, such as Tailscale, WireGuard, or UniFi Teleport,

which would let the existing internal links keep working.

• Public reverse-proxy access only after adding an MFA/SSO layer such as

Cloudflare Access, Authentik, Authelia, or another deliberate gate.

• A separate remote-safe Homepage configuration that links only to

intentionally exposed services such as Seerr and, later, Grafana if

hardened.

• Do not expose Homepage directly to the internet as a plain Caddy upstream until

the access model is chosen and reviewed.

Reference:

synology/docker/projects/homepage-compose/README.md
diagrams/PUBLIC_EXPOSURE.md
synology/docker/projects/reverse-proxy-compose/README.md

Arr Preference Monitoring

Status: direct Sonarr/Radarr helpers are authoritative; Recyclarr is

reference-only unless explicitly reactivated.

• On 2026-05-27, the storage-conscious policy expanded to:
• Sonarr 1080
• Sonarr Reality
• Radarr HD - 720p/1080p
• Separate direct helpers also applied:
• non-Anime x265/HEVC preference
• WEB 1080p cutoff / Bluray avoidance on the main non-Anime profiles
• targeted 720p/1080p size caps without Recyclarr quality-definition drift
• Anime remains intentionally untouched.
• Latest direct audit on 2026-06-03:

synology/docker/arr-preference-audit/20260603-221118/SUMMARY.md

showed 31 pass, 0 warn, 0 fail. This includes the main Radarr profile

change that disables 720p and lower movie grabs.

• Follow-up focus is no longer "whether to apply Radarr" but whether the new

non-Anime profile behavior is acceptable in practice for incoming grabs.

Reference:

synology/docker/RECYCLARR_PLAN.md

Bazarr Subtitle Pilot

Status: retired 2026-06-14.

Bazarr was added as a conservative subtitle pilot, but the user removed the

webhook and approved retirement because the service kept creating log noise and

had not proven useful. Keep the old plan and helper scripts as historical

reference only; do not expect a running Bazarr container, public route,

Homepage card, or Prometheus probe.

Future subtitle work, if reopened, should start with a fresh decision about

whether subtitles are worth automating at all. If they are, prefer a small

manual test scope before recreating an always-on service.

Reference:

synology/docker/BAZARR_PLAN.md

Audiobook External Access And Ebook Follow-Up

Status: Audiobookshelf remains; ReadAIrr retired 2026-06-14; public access and

manual ingestion workflow remain.

• Audiobookshelf was promoted to the audiobook project on 2026-06-04.
• Audiobookshelf is the intended user-facing app and may later be exposed as

https://audiobooks.ravick5.com for ShelfPlayer/app access.

• ReadAIrr and ReadAIrr Postgres were retired from the active stack on

2026-06-14 after repeated expensive rescans and bad imports. Do not recreate

them unless the user explicitly reopens audiobook automation.

• Before exposing Audiobookshelf, add it deliberately to Caddy, review account

roles, test mobile-app login, and decide whether additional auth/VPN is

needed.

• OpenAudible should remain a staging workflow, not a direct writer into the

live Audiobookshelf library. Use a staging folder and move reviewed finished

files into the organized library path.

• Reading services now live in the separate reading project. Keep Kavita

internal-only until account setup, library scans, and access policy are

reviewed; keep Mylar3 disconnected from indexers/download clients until the

comic/manhwa acquisition workflow is explicitly approved.

• Avoid additional book/audiobook containers for now. Stabilize the current

Audiobookshelf, Kavita, and Mylar3 setup first, then decide whether Mylar3 is

worth keeping.

Reference:

synology/docker/projects/audiobook-compose/README.md
synology/docker/projects/reading-compose/README.md
synology/docker/CONTAINER_FOOTPRINT_REVIEW.md
diagrams/PUBLIC_EXPOSURE.md

Optional Media/Arr Tooling To Evaluate

Status: evaluation only; do not add containers by default.

The current preference is to avoid additional always-on containers unless they

replace real manual work or improve safety/visibility. The existing stack is

already broad: Sonarr, Radarr, Lidarr, Prowlarr, NZBHydra2, NZBGet,

qBittorrent/Gluetun, Seerr, Tdarr, Tautulli, Audiobookshelf, Kavita, and Mylar3.

Candidate tools worth evaluating later:

• Maintainerr: useful if the user wants rule-based stale-media review and

cleanup tied to Plex plus Sonarr/Radarr/Seerr. Treat as high-risk until a

dry-run and approval workflow is designed because it can delete files,

unmonitor items, and clear request records.

• Kometa: useful for Plex collections, overlays, playlist/metadata automation,

and library presentation. This may replace some manual playlist/collection

work, but it should start as scheduled/manual config generation rather than

a constantly changing production process.

• Profilarr or Recyclarr/Configarr-style profile tooling: useful for testing

and managing Sonarr/Radarr profiles and custom formats, especially Anime.

Current VHNIC policy still keeps direct API helpers authoritative because

previous Recyclarr use risked broader quality-definition drift.

• Notifiarr: useful if the user wants a broader media notification/control

plane for Plex, Radarr/Sonarr, Tautulli, and health checks. Existing

Prometheus/Alertmanager plus Seerr Discord notifications already cover the

most important local alerting path, so this should not be added just for

novelty.

• Wizarr or similar onboarding tools: useful only if many Plex users need

guided setup. Not needed for the current small/private environment unless

user onboarding becomes a real chore.

Items that are lower priority right now:

• Adding another request app. Seerr is already the request front door.
• Adding another indexer/meta-search layer. Prowlarr plus NZBHydra2 already

exists.

• Adding more book/comic automation before the Audiobookshelf/Kavita/Mylar3

workflow proves what is actually missing.

• Adding deletion automation before appdata backups, retention rules, and

explicit dry-run review are comfortable.

Recommended next step after Tdarr finishes this evening:

1. Capture Tdarr progress and health.

2. Review residual non-HEVC/legacy codec buckets.

3. Decide whether Anime deserves a tiny custom-profile test set.

4. Only after that, choose one optional tool to evaluate, preferably Kometa for

low-risk Plex organization or Maintainerr in dry-run-only mode for cleanup

planning.

Reference:

synology/docker/CONTAINER_FOOTPRINT_REVIEW.md
synology/docker/tdarr/ANIME_PROFILE_PLAN.md

Seerr Request Notifications

Status: configured, pending Seerr restart.

• On 2026-06-01, synology/docker/seerr/Enable-SeerrDiscordNotifications.ps1

updated Seerr's Discord notification agent using the protected webhook already

stored on the Synology.

• The helper backed up:

/volume1/docker/seerr/settings.json.codex-before-discord-notifications-20260601-223141

• Notification scope is intentionally admin/request focused:
• request pending/new,
• request approved,
• request auto-approved,
• request declined,
• request failed,
• issue reported,
• issue comment.
• Poster embeds and role mentions are disabled to reduce Discord noise.
• Availability/import notifications remain disabled until the request workflow

is proven.

• Seerr still needs a container restart for the settings to be active.
• Alternative: ntfy for push notifications if Discord is not desired.
• After admin notifications work, decide whether requester/user-facing email or

Plex-user notifications are worth adding.

• Do not store webhook URLs, tokens, SMTP passwords, or API secrets in tracked

docs.

Reference:

synology/docker/OVERSEERR_REVIEW.md
synology/docker/projects/seerr-compose/README.md

Pi-hole

Pi-hole Metrics Exporter

Status: future enhancement.

• Grafana currently monitors both Pi-holes through Blackbox DNS probes only.
• Pi-hole v6 API endpoints returned 401 Unauthorized without auth, so deeper

query/block/client stats were intentionally not added.

• Future options:
• use an authenticated Pi-hole API exporter with a protected secret strategy,
• install a narrow local helper/exporter on each Pi-hole,
• or keep DNS probe health only.
• Do not put Pi-hole API passwords/tokens in tracked docs.

Reference:

synology/docker/projects/observability-compose/CURRENT_STATE.md
pihole/CURRENT_STATE.md

Upstream DNS Simplification

Status: helper prepared; live application not confirmed in tracked docs.

Current behavior is functional. Older tracked captures show many built-in

providers enabled, while dns.upstreams = [] appears to mean no custom

upstreams are configured. A narrow helper now exists at

tools/pihole/Set-PiholeSharedUpstreams.ps1 to apply Quad9 filtered IPv4

upstreams to both Pi-holes, but do not claim that policy is active until a fresh

capture verifies live dns.upstreams.

Future recommendation to review:

• Simplify to a smaller explicit upstream strategy if the user still wants it.
• Candidate: Quad9 filtered IPv4, using the prepared helper after previewing

and verifying current state.

• Avoid making the Pi-holes use each other as their only upstreams.
• Do not change this until the user is comfortable with the DNS policy choice.

Reference:

pihole/CONFIG_REVIEW.md
pihole/HANDOFF.md

Pi-hole OS Update Policy

Status: recommendation documented; no automatic OS patching enabled.

Both Pi-holes have apt metadata timers enabled and Pi-hole's own gravity/update

cron jobs present. Neither Pi-hole currently has unattended-upgrades

installed or configured.

Recommendation:

• Keep Pi-hole application upgrades manual and deliberate.
• Keep gravity refresh automated through Pi-hole's normal cron job.
• Use controlled OS patch windows rather than broad unattended upgrades.
• Do not enable automatic reboot.
• Use the read-only helper before patch windows:

powershell -NoProfile -ExecutionPolicy Bypass -File .\tools\pihole\Capture-PiholeUpdateReadiness.ps1

Reasoning:

• PiHole4B has a clean Debian trixie security repository and may be a future

candidate for security-only unattended upgrades.

• PiHolePi4 uses Raspberry Pi/Raspbian bookworm repositories, where a generic

unattended-upgrades policy could apply broader changes than intended.

• DNS infrastructure should fail boringly. Planned patching is safer than

surprise automatic changes across both DNS servers.

Reference:

pihole/OS_UPDATE_POLICY.md

PiHoleEx Replacement

Status: completed 2026-06-13.

• The old Raspberry Pi 2-based PiHoleEx was replaced with the spare Raspberry

Pi 4 Model B Rev 1.5.

• The replacement hostname is PiHole4B.
• The secondary DNS role and production IP 10.0.0.132 were preserved.
• Pi-hole configuration was restored from the latest PiHoleEx Teleporter

backup.

• Wi-Fi is disabled/down on the replacement; Ethernet owns 10.0.0.132.
• Narrow Codex maintenance helpers were reinstalled for codex-maint.
• Post-cutover inventory snapshot:

pihole/inventory/snapshots/20260613-153931.

Follow-up:

• Let PiHole4B run long enough to prove stability.
• Decide whether to keep the old PiHoleEx/Pi 2 SD card as a cold rollback

artifact or retire it.

Reference:

pihole/PIHOLEEX_PI4_REPLACEMENT.md
tools/pihole/Prepare-PiHoleExReplacement.ps1

Pi-hole Hostname Alignment

Status: future cleanup after PiHole4B cutover is stable.

• New secondary Pi-hole hostname is PiHole4B.
• Existing primary Pi-hole hostname PiHolePi4 should be renamed later to use

the same naming style.

• Do not do this during the PiHole4B cutover. Hostname changes should wait

until DNS service, backups, helper scripts, Homepage, Grafana, and docs are

all stable after the replacement.

• Future work should update the OS hostname, Pi-hole display name if needed,

UniFi client alias, local docs, backup folder naming if desired, and any

dashboard/Homepage labels in one coordinated pass.

UniFi

Observability Metrics Expansion

Status: first pass implemented; deeper counters still open.

• Grafana now includes a UniFi exporter using the local Integration API.
• Current live metrics include device state, wired/wireless client counts, and

wireless clients by AP.

• Still missing from the live dashboard:

WAN throughput,

switch-port throughput,

AP channel utilization,

retry rates,

roaming/client experience,

and PoE/uplink detail.

• Future work should use a supported API if possible; keep SSH/Mongo as an

on-demand audit path rather than the first choice for an always-on exporter.

Reference:

synology/docker/projects/observability-compose/CURRENT_STATE.md
unifi/HANDOFF.md

Deeper Network Review

Status: inventory and SSH/API access established; review incomplete.

• Review WAN speed/duplex and actual path from Frontier to UDM SE.
• Review uplinks between UDM SE, USW Pro 48, Synology, desktop, and APs.
• Confirm whether the Synology 10GbE links and desktop 5GbE path are negotiated

as expected.

• Review switch port profiles and any bottlenecks.

Reference:

unifi/HANDOFF.md
unifi/topology/README.md
unifi/system/README.md

Firewall, NAT, And Port Forward Review

Status: captured, not fully remediated.

• Review all existing port forwards and whether each is still needed.
• Prefer a reverse proxy with explicit service records over broad exposure.
• Keep public services intentional and documented.
• User wants the direct Seerr/legacy Overseerr forwards removed until proper reverse proxy

remediation is complete.

• 2026-05-22 verification found:
• Overseer public 5055 -> 5055 disabled.
• Overseerr public 80 -> 5055 disabled.
• QB public 6881 -> 6881 disabled.
• Minecraft-Oneblock public 19191 -> 19191 disabled.
• Plex Test public 32401 -> 32400 intentionally still enabled.
• HTTPS Routing public 443 -> 5055 later disabled and no longer live in

NAT as of the 2026-05-22 follow-up check.

• Do not change firewall/NAT rules without explicit approval.

Reference:

unifi/security/PORT_FORWARDS.md
unifi/security/DOMAIN_EXPOSURE.md
unifi/security/SECURITY_POSTURE_REVIEW.md

Wi-Fi Review

Status: initial config reviewed; first repeatable helper created; deeper live radio health counters still needed.

• Current AP plan appears broadly sane:
• 2.4 GHz: channels 1 and 11, 20 MHz.
• 5 GHz: channels 48 and 149, 40 MHz.
• 6 GHz: auto, 160 MHz.
• Latest Wi-Fi helper snapshot:

unifi/wifi/snapshots/20260621-073006.

• No current captured evidence proves Wi-Fi congestion.
• Both U7-Pro APs are set to high transmit power. Review this if clients become

sticky, roam poorly, or attach to the farther AP.

• First helper created:

powershell -NoProfile -ExecutionPolicy Bypass -File .\tools\unifi\Capture-UnifiWifiHealth.ps1

• Future helper improvement: capture channel utilization, interference/noise,

RSSI, retry rates, PHY mode, roaming events, AP uplink speed, and PoE state

if a reliable UniFi source exposes them.

• Tune only after collecting enough client/AP evidence. First likely tuning

target, if evidence supports it, is lowering 2.4 GHz power rather than

changing channel widths.

Reference:

unifi/wifi/README.md

Google Cloud DNS And Dynamic DNS

Dynamic Public IP Updater

Status: not implemented.

• Current public IP has been stable, but dynamic updating is still a useful

future safety net.

• Decide whether the updater should run from Synology, Raspberry Pi, or another

always-on host.

• Use the existing Google Cloud DNS service account carefully.
• Keep wildcard DNS removed unless there is a deliberate reason to restore it.

Reference:

google-cloud-dns/README.md

Docker And Media Automation

Tdarr Library Expansion

Status: broad rollout complete; Anime remains optional and separate.

• Do not add more normal TV/Movie-style libraries. Kids TV, Kids Movies,

Movies, TV Shows, and Reality are already covered.

• Anime is the only remaining plausible Tdarr library candidate, and it should

be treated as a controlled pilot with a custom stream-preserving profile.

• Watch SSD/cache behavior, transcode error rate, Plex impact, desktop GPU

load, and the 2026-06-11 finish-out queue before enabling any Anime workers.

• Keep GPU transcode count conservative while gaming; higher counts are better

suited for idle/overnight windows.

Reference:

synology/docker/tdarr/README.md

Tdarr Error Handling

Status: needs review before large-scale rollout.

• Review recurring transcode errors before they accumulate.
• Decide whether failed files should be retried with another plugin, left alone,

or replaced through Sonarr/Radarr.

• Avoid a workflow that wastes many hours repeatedly failing on the same class

of files.

Anime Automation

Status: partially improved, not finished.

• Sonarr Anime was adjusted toward dubbed 1080p behavior.
• User still wants better automation for dubbed Anime acquisition.
• Future review should include Sonarr profiles, release profiles/custom formats,

NZBHydra2 indexer behavior, and whether Standard series type remains the

better fit for the user's Anime library.

Reference:

synology/docker/OVERSEERR_REVIEW.md
synology/HANDOFF.md

qBittorrent And Gluetun

Status: review deferred while current VPN path remains stable.

• qBittorrent is currently connectable.
• User does not want VPN/port changes while it is working.
• The UniFi QB public forward 6881 -> 10.0.0.119:6881 is likely a relic

from the first setup and should be reviewed/remediated after md2 resync.

• Because qBittorrent is routed through Gluetun/ProtonVPN, a direct WAN forward

to the Synology is probably not useful unless intentionally bypassing VPN,

which is not the current design.

• Future review can check whether Gluetun HTTP proxy and Shadowsocks are needed.
• Continue avoiding Watchtower auto-updates for pinned/problematic containers.

Reference:

synology/docker/VPN_QBIT_NZBHYDRA_REVIEW.md

NZBGet Secret Hygiene

Status: future cleanup.

• NZBGet is functional after the 2026-05-21 path fix for CertStore and

SevenZipCmd.

• Future cleanup should move web UI credentials out of tracked Compose YAML and

into a local .env or another untracked secret location.

• Avoid posting NZBGet server credentials or web UI secrets into chat or tracked

docs.

Hardware Planning

Former SSD Cache Bays

Status: future planning only.

• Do not reuse the removed cache SSDs for production.
• Best discussed future option: two new 2TB or larger endurance/NAS SSDs as a

mirrored Volume 3 for high-churn app workloads.

• Alternative options discussed:

add more HDD capacity to Volume 1, add larger SSDs to Volume 2, or leave bays

empty until a clearer need appears.

• Do not move appdata again until after the current storage maintenance and

Btrfs follow-up are stable.

Reference:

synology/HANDOFF.md
synology/storage/CURRENT_STATE.md

Spare Raspberry Pi 4

Status: now serving as PiHole4B, the secondary Pi-hole replacement.

Potential future uses:

• Reverse proxy host.
• DNS/DDNS control-plane duties.
• Monitoring node.
• Potential future internal reverse proxy host after the Pi-hole replacement is

stable, though this is optional rather than required.

Raspberry Pi 5 Arcade Cabinet Refresh

Status: future project candidate.

• A Raspberry Pi 5 is available and is better reserved for the arcade cabinet

refresh than for secondary Pi-hole duty.

• Goal: replace the very old Android TV box currently inside the arcade cabinet.
• Future planning should compare Batocera, RetroPie, Recalbox, and any cabinet

control-panel/input requirements before imaging.

• Capture current cabinet details before implementation:

display connection/resolution, controller encoder type, button mapping,

audio path, power behavior, and whether any existing game/media files need to

be preserved.

• Keep this separate from the PiHoleEx replacement so the Pi-hole cutover can

stay simple and low-risk.

Lower Priority Cleanup

• Review old NZBHydra2 backups after the new retention policy has had time to

run.

• Confirm Synology DSM alerts remain enabled and useful.
• Keep /volume1 below the agreed comfort threshold over time.
• Revisit Plex remote 480p complaints from the remote user's location before

assuming the Synology is the bottleneck.