Docker Implementation Guide¶

v2.2 | Build 013.20260815.180509Z

Implementation guide for Docker in the McGuckin.Net environment.

McGuckin Docker Environment

Docker Implementation Guide

Version 0.13 | August 15, 2026

Table of Contents

1. Document Metadata 4

2. Purpose and Scope 5

2.1 Purpose 5

2.2 Scope 5

3. Design Principles 5

3.1 Reproducibility 5

3.2 Separation of Roles 5

3.3 Least Necessary Exposure 5

3.4 Durable State 5

4. Host and Runtime Baseline 6

5. Current Docker Projects 6

5.1 Caddy 6

5.2 FlareSolverr 6

6. Caddy Architecture 7

6.1 Request Path 7

6.2 Certificate Path 7

6.3 Current and Approved Service Routes 7

7. Configuration and Persistence 9

7.1 Project Layout 9

7.2 Runtime Controls 9

8. Network and Security Boundaries 10

9. Operations and Change Control 11

10. Backup and Recovery 13

10.2 Immutable Offsite Backup - Arq 7 and Backblaze B2 14

11. Current Deviations and Decisions 17

12. Approved Application Portfolio 19

13. Installation and Compose Templates 21

14. Resource Capacity Planning 29

Appendix A - Ports and Endpoints 35

Appendix B - Recovery Checklist 36

Appendix C - Revision History 37

1. Document Metadata¶

2. Purpose and Scope¶

2.1 Purpose¶

This guide documents the Docker environment currently operating on JUKEBOX and the approved portfolio planned for deployment. It records what each component does, how it is deployed, how much capacity it is expected to consume, and how it is operated and recovered.

2.2 Scope¶

• Docker Desktop runtime and host dependencies on JUKEBOX.

• The Caddy and FlareSolverr Compose projects and Caddy-routed JUKEBOX applications.

• Caddy TLS, DNS, proxy, logging, secret, and persistence design.

• Routine validation, deployment, backup, rollback, recovery, and resource-capacity expectations.

• The approved application portfolio, permanent three-letter keys, standardized deployment patterns, and planning resource budgets.

• Known differences between the current implementation and NET-003.

Native macOS application configuration, media-library administration, and general network addressing remain outside this guide except where Docker depends on them.

3. Design Principles¶

3.1 Reproducibility¶

A running container is not the system of record. Compose definitions, configuration files, secrets references, and persistent state must be sufficient to recreate the service.

3.2 Separation of Roles¶

Docker provides isolated runtime packaging; Caddy provides the HTTPS edge; UniFi and Cloudflare provide different DNS functions; native macOS applications remain independent backends.

3.3 Least Necessary Exposure¶

Only ports needed for an intentional client or integration are published. Administrative applications use UniFi VPN as the approved remote-access boundary while Caddy provides HTTPS routing for LAN and VPN clients. Public Caddy exposure is reserved for services explicitly approved for access without the VPN. Local appliances such as Home Assistant and HDHomeRun are not proxied merely to make their names shorter.

3.4 Durable State¶

Containers and images are replaceable. Configuration, certificates, keys, logs, and application state must persist outside the disposable container filesystem.

4. Host and Runtime Baseline¶

5. Current Docker Projects¶

6. Caddy Architecture¶

6.1 Request Path¶

1. A client resolves a service name through UniFi split-horizon DNS on the LAN or Cloudflare public DNS remotely.

2. The client connects to JUKEBOX on TCP 443; TCP 80 is retained only for automatic redirection to HTTPS.

3. Caddy selects a site block from the requested hostname and presents that hostname's certificate.

4. Caddy connects through host.docker.internal to the application running directly on macOS.

5. The application response returns through Caddy over the established encrypted client connection.

6. IMPLEMENTED STATE — Docker Desktop presents inbound connections to Caddy through its gateway address, so Caddy source-address matching is not used as the security boundary. JUKEBOX TCP 443 is the private listener for all documented HTTPS routes. UniFi WAN TCP 443 forwards to JUKEBOX TCP 8443, and Caddy TCP 8443 contains only the plex.mcguckin.net application route. Administrative services, including plexstats.mcguckin.net, remain available through TCP 443 from the LAN or UniFi VPN and are absent from the WAN-forwarded listener.

7. VERIFICATION RECORD — On August 14, 2026, every private Caddy route reached its expected login or application endpoint from the LAN. The WAN-forwarded listener reached Plex and returned no application content for tested administrative hostnames. Public DNS returned no AAAA records for the Caddy service names, preventing an IPv6 bypass of the IPv4 forwarding boundary. A live connection from a remote UniFi VPN client remains an operational follow-up.

6.2 Certificate Path¶

The standard Caddy image does not contain the Cloudflare DNS provider. A pinned, multi-stage Docker build compiles Caddy 2.11.4 with that module, then copies only the resulting binary into the production image. This keeps build tooling out of the runtime while enabling DNS-01 certificate validation.

DNS-01 proves control of mcguckin.net through temporary Cloudflare TXT records. It does not require the backend application to answer an internet certificate challenge, and it permits certificates for split-horizon service names.

6.3 Current and Approved Service Routes¶

The following names are approved for planned Docker containers that need stable identity. UniFi DNS publishes each name as an internal CNAME to jukebox.mcguckin.net. Caddy receives only supported HTTP endpoints; background workers retain a stable DNS identity without a false web route. Transmission remains native and retains its existing local access path; no qbittorrent.mcguckin.net record is approved.

7. Configuration and Persistence¶

7.1 Caddy Project Layout¶

7.2 Runtime Controls¶

8. Network and Security Boundaries¶

The gateway forwards WAN TCP 80 to JUKEBOX TCP 80 and WAN TCP 443 to JUKEBOX TCP 8443. Docker publishes TCP 80, private TCP 443, UDP 443, and the Plex-only TCP 8443 listener for Caddy. JUKEBOX TCP 443 is not the target of a WAN port forward. Backend application ports remain native macOS listeners reached through host.docker.internal.

IMPLEMENTED BOUNDARY — The absence of a WAN forward to JUKEBOX TCP 443 is the administrative-service boundary. UniFi VPN clients use the same private TCP 443 listener as LAN clients. WAN TCP 443 reaches the Plex listener on JUKEBOX TCP 8443. Rollback restores Caddyfile.backup-before-split-listener-20260814-220959 and docker-compose.yml.backup-before-split-listener-20260814-220959, recreates Caddy, and changes the UniFi HTTPS forward from internal TCP 8443 back to internal TCP 443.

8.1 Native Torrent Privacy Path¶

APPROVED DECISION Transmission remains a native macOS application. The qBittorrent container migration is cancelled because Docker Desktop presents all container egress to macOS as com.docker.backend; a PIA application rule would therefore govern Docker collectively rather than isolate one torrent container.

• PIA split tunneling is enabled and Transmission is explicitly assigned Only VPN. All Other Apps follows the separately approved host policy; Docker Desktop is not used as the torrent privacy boundary.

• PIA VPN Kill Switch is enabled. Allow LAN Traffic may remain enabled so the Transmission interface and local integrations remain reachable without permitting public torrent egress outside the VPN.

• Before Transmission is released to Prowlarr or any Arr application, the startup gate verifies PIA reports Connected, PIA reports a VPN address, Transmission is running, a Transmission-originated egress check shows the PIA address, and a controlled PIA disconnect prevents Transmission internet traffic.

• If any gate fails, Transmission pauses or stops, its network-dependent automation remains blocked, and the operator is alerted. Usenet workflows may continue through SABnzbd when independently healthy.

• The test is repeated after every PIA, macOS, or Transmission update and after any split-tunnel rule change. No document statement substitutes for a live leak and failure test on JUKEBOX.

9. Operations and Change Control¶

9.1 Safe Caddy Configuration Change¶

1. Update the governing standard and implementation guide with the intended change, rollback path, and Pending status.

2. Create a timestamped backup of the current Caddyfile.

3. Make the smallest necessary edit and update adjacent explanatory comments.

4. Run the project validation command using the normal secret-loading entrypoint.

5. Review the exact file difference before installation.

6. Reload Caddy gracefully; do not recreate the container for a routing-only change.

7. Test every retained service and confirm removed hostnames are no longer served.

9.2 Image or Compose Change¶

A Caddy version, image, port, mount, health-check, or security change requires Compose validation and controlled container recreation. The CADDY_VERSION build argument and local image tag must remain synchronized. Rebuilds are deliberate because the Cloudflare provider is compiled into the image.

9.3 FlareSolverr Operations¶

FlareSolverr is independently managed from ~/Containers/flaresolverr. Prowlarr reaches its published host port 8191. It is not a Caddy website and must not receive public DNS or a gateway port-forward.

9.4 Routine Verification¶

• Confirm both containers are running after a host or Docker Desktop restart.

• Confirm Caddy reports healthy and every documented HTTPS route reaches its expected application endpoint from its approved access boundary.

• Review Caddy logs for certificate, upstream, authentication, or repeated probing errors.

• Verify persistent volumes are mounted before destructive cleanup or image pruning.

10. Backup and Recovery¶

10.1 Recovery Sequence¶

1. Restore macOS and start Docker Desktop under the normal JUKEBOX user session.

2. Restore the Caddy and FlareSolverr project directories and required persistent state.

3. Restore the Cloudflare token with directory mode 700 and file mode 600.

4. Build and validate the custom Caddy image before starting production traffic.

5. Start Caddy, wait for a healthy state, and inspect certificate logs.

6. Start FlareSolverr and verify port 8191 from the local host only.

7. Test every documented Caddy URL from its approved LAN, VPN, or public boundary and test the direct local Home Assistant and HDHomeRun names.

10.2 Immutable Offsite Backup - Arq 7 and Backblaze B2¶

OFFICIAL DECISION JUKEBOX shall use a licensed Arq 7 native macOS client with a dedicated private Backblaze B2 bucket as its immutable offsite backup platform. Arq must connect through B2's S3-compatible endpoint because Arq's native B2 storage type does not support Object Lock. The cloud copy supplements application-native exports, Restic, and Time Machine; it does not replace them.

10.2.1 Recovery Scope and Retention¶

Phase 1 protects the compact recovery set first. Phase 2 adds larger application-state datasets only after the first seed, restore test, bandwidth behavior, and monthly cost are accepted.

Plex sizing baseline: Finder reported 482.88 GB used on PlexDB on August 15, 2026. That figure is a conservative planning ceiling because it includes more than /Volumes/PlexDB/Plex; measure the exact Plex tree before commissioning. The 44 TB Storage media library is not an Arq/B2 target.

Retention baseline: enable Arq immutable backup records for a minimum of 35 days and refresh locks every 7 days. Maintain at least daily successful runs so Arq can extend locks on deduplicated objects. Arq thinning and budget cleanup cannot delete a locked object until its lock expires.

10.2.2 Dependencies and Software Requirements¶

10.2.3 Implementation Procedure¶

1. Create or secure the Backblaze account: use a unique password, enable multi-factor authentication, save recovery codes offline, and add a billing method and budget alert.

2. Create a new private B2 bucket dedicated to JUKEBOX. Enable Object Lock before the production upload. Record the bucket name, S3 endpoint, and region. Object Lock cannot be treated as active until a locked test object is verified.

3. Create a standard B2 application key restricted to the JUKEBOX bucket with the read/write permissions Arq requires. Do not provide Arq the master application key. Record the key ID and secret once in the approved credential store; never place them in Compose, Git, or documentation.

4. Install Arq 7 as a native macOS application on JUKEBOX and purchase the one-computer license after the trial validates the workflow.

5. In Arq, choose New Storage Location, select S3-Compatible Server, enter https:// plus the B2 S3 endpoint, supply the bucket-scoped key ID and secret, and enter the region from the endpoint. Do not select Arq's native Backblaze B2 storage type for this plan because that path cannot enable Object Lock.

6. Create the JUKEBOX-Immutable backup plan. Enable Arq client-side encryption with a new strong password, save the password and recovery instructions offline, and verify that a second authorized device or printed recovery record can supply them after total host loss.

7. Select Phase 1 paths first. Explicitly exclude Storage media, Downloads, caches, temporary files, TARDIS, local Restic repositories, Docker Desktop VM data, and routine logs. After the Phase 1 restore test, add the Docker durable-state paths and the complete /Volumes/PlexDB/Plex tree.

8. Enable Make latest backup record immutable. Set the initial policy to a minimum 35 days with a 7-day refresh interval. Use compliance mode through Arq; do not grant the client bypass-governance authority.

9. Schedule Arq for the 3:20-4:20 a.m. Eastern slot after application-native exports and Restic. Configure the backup gate to require mounted sources, a successful Arq result, a current backup record, and no reported errors before any upgrade starts.

10. Run the initial seed as a commissioning job. Keep it outside normal update activity, allow it to continue across dedicated overnight windows if needed, and defer routine upgrades until the first complete immutable backup and sample restore pass.

11. Restore representative files from each Phase 1 path to the separate restore target. Verify hashes or application readability. Then restore one Docker application configuration and a representative Plex database or metadata item before authorizing Phase 2 as operational.

12. Record the actual protected byte count, first-seed duration, routine incremental duration, B2 stored bytes, estimated monthly charge, lock expiry range, test results, and rollback instructions in the implementation record. Reconcile NET-004 only after the production plan is verified.

10.2.4 Operating and Recovery Controls¶

• BACKUP-BEFORE-UPGRADE GATE Application-native exports, Restic, and Arq/B2 must all report successful and current recovery points before routine application, container, Docker Desktop, or macOS upgrades begin. A failed or unverified layer changes the window to diagnostics and backup repair only.

• Emergency security exception: an urgent security update may proceed only with documented owner approval, a verified current local recovery point, a specific rollback plan, and a post-change offsite backup. This is an exception, not the routine path.

• Review Arq and B2 status daily. Investigate missed runs, missing source volumes, credential failures, lock-refresh failures, unexpected stored-byte growth, and cost alerts before the next maintenance window.

• Perform a monthly sample restore from B2 and a quarterly full recovery exercise covering credentials, Arq installation, S3-compatible attachment, plan adoption, decryption, representative native application data, one Docker service, and Plex state. A backup is not accepted solely because upload completed.

• If JUKEBOX or Arq is compromised, disconnect it from B2, preserve logs, rotate the B2 application key and Backblaze credentials from a clean device, recover hidden/deleted backup records if necessary, and restore into a clean target. Object Lock protects locked object versions but does not replace account security or client-side encryption.

10.2.5 Projected Costs¶

Pricing was verified from Arq and Backblaze on August 15, 2026 and remains subject to vendor change, taxes, actual byte-hours, transaction mix, and egress. B2 calculations below use $6.95 per TB per month and round to the nearest cent. CONSERVATIVE BUDGETING RULE — When credible official prices conflict, a published range exists, or an announced increase is relevant, planning shall use the highest credible amount. The estimate must identify the source and verification date and must be verified again before purchase or renewal.

Cost-control rule: after commissioning, compare B2 stored bytes and the invoice to the measured protected set each month. Investigate growth above forecast before increasing the budget. Immutability can delay deletion of superseded objects until locks expire, so storage may temporarily exceed the live protected dataset.

10.2.6 Authoritative References¶

• Arq immutable backup records: https://www.arqbackup.com/documentation/arq7/English.lproj/objectLock.html

• Arq immutable B2 setup: https://www.arqbackup.com/documentation/arq7/English.lproj/addB2AsS3Compatible.html

• Arq pricing: https://www.arqbackup.com/pricing/

• Backblaze B2 Object Lock: https://www.backblaze.com/docs/cloud-storage-object-lock

• Backblaze B2 pricing: https://www.backblaze.com/cloud-storage/pricing

• Backblaze B2 application keys: https://www.backblaze.com/docs/en/cloud-storage-application-keys

• Plex Media Server backup guidance: https://support.plex.tv/articles/201539237-backing-up-plex-media-server-data/

11. Current Deviations and Decisions¶

The following items document the current as-built state without silently treating it as the NET-003 target architecture. Each should be resolved deliberately rather than through opportunistic cleanup.

12. Approved Application Portfolio¶

The portfolio below is the approved application scope for JUKEBOX. Installed status distinguishes the current as-built environment from future container deployments. Approval does not authorize deployment until the documentation-first change gate, prerequisites, backup, and rollback requirements are satisfied.

12.1 Portfolio Status Rules¶

• INSTALLED is factual: Yes - Native, Yes - Container, or No. It does not encode approval, feasibility, migration, or retirement intent.

• DEPLOYMENT STATE is controlled: Implemented - Native, Implemented - Container, Approved - Pending, or Conditional. Approved - Pending still requires the documentation-first change gate before deployment.

• Transmission is the permanent native BitTorrent client. It is not a migration source, and qBittorrent is not in the approved portfolio.

• Docker Desktop is inventoried because it is the platform dependency, but DKR is not a container and is excluded from container totals.

• Grafana dependencies are inventoried independently because they consume resources and require separate recovery inputs.

13. Installation and Compose Templates¶

This chapter defines the repeatable installation method for the portfolio. Application-specific values belong in the project-local .env and compose.yaml files; secrets are externalized. Templates are authoritative patterns, not permission to deploy every service simultaneously.

13.1 Standard Installation Sequence¶

1. Update NET-004 with the intended app key, image version, ports, dependencies, Caddy name, resource budget, backup scope, rollback, and Pending status.

2. Create /Volumes/PlexDB/Docker/compose/\<app-name> and /Volumes/PlexDB/Docker/appdata/\<app-name>; confirm PlexDB and Storage are mounted.

3. Create the project-local .env and compose.yaml from the approved template. Use explicit stable image versions; do not use development, nightly, edge, or floating latest tags unless a documented exception exists.

4. Validate the resolved Compose configuration and confirm that no secret is printed or embedded in the recipe.

5. Take or verify the application backup, then pull the approved image and create only the intended project.

6. Complete the application setup wizard, authentication, paths, API keys, and service-to-service integrations.

7. Add the approved Caddy route and UniFi DNS alias only after the direct backend health check passes.

8. Verify application function, persistence after recreation, logs, backup capture, Uptime Kuma monitoring, and resource behavior.

9. Reconcile NET-004 from Pending to Implemented, recording the actual image, ports, paths, measured resources, result, and any deviation.

13.2 Common Environment Baseline¶

Project-local .env pattern¶

• PUID, PGID, Storage paths, and image tags must be resolved from JUKEBOX immediately before deployment. Placeholder values are never valid production settings.

Template A - Standard web service¶

Template B - Media manager or download client¶

Template C - Scheduled job¶

Template D - Docker control-plane service¶

Template E - Monitoring service¶

13.2.1 Required Readiness Contract¶

Every boot container must implement the health-check pattern above or declare an approved external probe in its README. The project records the probe, interval, timeout, retry budget, start period, total readiness deadline, failure effect, and rollback command. Compose service_healthy may control dependencies within one project; the JUKEBOX startup orchestrator controls cross-project order. Placeholder probes fail the deployment gate.

13.3 Application Deployment Matrix¶

Image names identify the approved upstream family. The exact stable tag must be recorded in the project .env and implementation record at deployment time. Native applications are included only when they are continuing platform or security prerequisites. Plex and Transmission have no container image or migration recipe in this guide.

13.4 Application-Specific Gates¶

• TRA: retain native Transmission; require PIA Only VPN routing, VPN Kill Switch, PIA connected/VPN-IP checks, an application-originated egress-IP check, and a controlled disconnect test before enabling torrent automation.

• PLE: Plex Media Server remains native on macOS. Containerization is not an approved present or future target in NET-004.

• SCR: do not deploy until Docker Desktop can expose the required physical SMART devices safely; otherwise use a native collector or omit Scrutiny.

• NDE and CAV: Node Exporter is explicitly scoped to the Docker Linux VM when containerized; cAdvisor reports per-container metrics. Dashboards must not label either source as JUKEBOX macOS host metrics.

• WUD: begin in report/manual mode; approve automatic triggers only after Compose-file backups, application backups, tag filters, and recovery tests work.

• RES: complete a restore test. A successful backup command without a verified restore does not satisfy the recovery gate.

• REC and KOM: preview or dry-run configuration changes before enabling scheduled writes.

13.5 Canonical Container Recipe¶

The canonical project scaffold is stored at Templates/Docker-Container-Recipe/. Copy it into an application project directory, then resolve the approved app key, image and immutable tag, ports, paths, networks, health check, resource budget, backup scope, and rollback method before deployment. The scaffold consists of compose.yaml, .env.example, and README.md.

A template is not a deployable stack. Any REPLACE value, example image, unresolved path, absent health check, or unapproved app key fails the deployment gate.

13.6 Startup Orchestration¶

Startup is controlled by readiness gates, not elapsed time alone. The JUKEBOX startup orchestrator begins only after the non-Docker prerequisites pass, then releases containers in numbered order. A higher number does not start until its declared dependencies are healthy or an approved degraded-start branch applies.

CONTROL RULE The NUMBER field is an ordering key, not a delay in seconds. Ten-point increments preserve space for future insertions. STARTUP MODE distinguishes boot, conditional, scheduled, and manual behavior; READY WHEN is the machine-testable release gate; FAILURE EFFECT defines whether downstream work halts or continues degraded.

13.6.1 Non-Docker Startup Table¶

These host prerequisites execute before the Docker Startup Table. Storage, network, service-session, Docker Engine, and orchestrator failures stop the Docker sequence. Native Plex uses the documented degraded branch. PIA and Transmission gate torrent automation but do not block independently healthy Usenet workflows. Native SABnzbd gates Usenet-dependent automation but does not block independently healthy torrent or platform workflows.

13.6.2 Docker Startup Table¶

This table contains all 25 approved target containers, including services currently native to macOS but still planned for container migration. Docker Desktop, native Plex Media Server, native Transmission, and native SABnzbd are not containers and appear only as prerequisites or continuing native dependencies.

SCHEDULED-JOB BOUNDARY Restic, Recyclarr, and Kometa remain stopped during an ordinary reboot. The maintenance-window scheduler starts them only in their assigned slots. Scrutiny and the host-exporter design remain conditional until their macOS and Docker Desktop feasibility gates are approved.

13.6.3 Startup Authority and Recovery¶

The macOS launchd service for the JUKEBOX startup orchestrator is the sole boot authority for orchestrated Compose projects. Before that controller is activated, every governed boot container - including Caddy and FlareSolverr - must use restart: no so Docker cannot bypass the documented order after a daemon or host restart.

Within a Compose project, health checks and depends_on with condition: service_healthy may release local dependencies. Across projects, only the startup plan may issue starts. A single-run lock prevents concurrent startup sequences.

Runtime crash recovery is separate from boot ordering. After a service has passed readiness, the orchestrator may attempt up to three restarts in fifteen minutes with exponential backoff. Exhausting the budget marks the service failed, applies its documented downstream failure effect, preserves logs, and alerts the operator. Scheduled-only containers are never restarted outside their maintenance slot.

14. Resource Capacity Planning¶

Capacity planning prevents the approved portfolio from exhausting JUKEBOX or the Docker Desktop virtual machine. Values below are initial engineering estimates for sizing and rollout order; they are not vendor guarantees or measured production values. Every deployed service must replace its estimate with observed idle, normal, and peak measurements.

14.1 Planning Method¶

• Idle RAM is the expected stable working set after startup with no intensive task running.

• Burst RAM is a planning high-water mark during scans, searches, dashboard queries, backup, unpack, browser automation, or transcoding.

• CPU ranges indicate expected active cores, not reservations. Summing every peak is intentionally conservative because heavy tasks must be scheduled apart.

• Media files are excluded from application storage. Plex metadata, Prometheus retention, Scrutiny time-series data, logs, images, and backup caches remain platform-capacity consumers.

• Resource budgets are observation targets. Hard container limits are added only after stable workloads are measured and recovery behavior is tested.

14.2 Per-Container Planning Estimates¶

14.2.1 Estimate Provenance¶

Every value in Section 14.2 is an engineering planning allowance, not a measurement or vendor guarantee. The companion table records basis, verification state, and confidence without over-widening the operating table. Replace each row with observed idle, normal, and peak measurements during staged deployment.

14.3 Aggregate Capacity Model¶

14.4 Storage and Retention Budget¶

14.5 Maintenance Window and Workload Scheduling¶

OFFICIAL MAINTENANCE WINDOW Scheduled maintenance is authorized only from 12:00 a.m. through 8:00 a.m. Eastern Time. All work must finish by 8:00 a.m.; activity outside the window requires a separately documented exception.

Heavy-I/O jobs run sequentially and never overlap. Application-native exports, Restic, and Arq/B2 run before upgrades and form a mandatory go/no-go gate. If a backup fails or a task overruns its slot, upgrades and later optional work are deferred rather than compressed or run concurrently. Monitoring remains active throughout the window.

MACOS UPDATE NIGHT EXCEPTION Backups and the 4:20-4:30 go/no-go gate still run first. A larger or restart-requiring macOS update replaces the 6:00-7:00 heavy-job slot and any lower-priority work needed to preserve recovery time. Begin only when installation, restart, and verification of macOS, Plex, Docker Desktop, containers, Caddy, storage, and network access can reasonably finish by 8:00; otherwise defer the update.

INITIAL-SEED EXCEPTION The first Arq upload is a commissioning activity, not a one-hour routine job. It may span multiple dedicated maintenance windows. During commissioning, suspend updates and optional heavy jobs until the immutable baseline and sample restore pass; stop or throttle the seed by 8:00 a.m. if daytime resource use would be affected.

14.6 Measurement and Acceptance Gate¶

• Record Docker Desktop memory and CPU allocation before each deployment wave.

• Capture 24-hour idle and seven-day normal utilization after each wave using Docker statistics and Prometheus/Grafana when available.

• Exercise each service's heavy path: native SAB repair/unpack, native Transmission peer load behind PIA, Plex stream/transcode, Kometa scan, Restic backup, and Prometheus compaction.

• Maintain at least 20% Docker memory headroom during normal operation and avoid sustained host memory pressure or swap growth.

• Alert at 70% sustained Docker memory, 80% short-term memory, 75% PlexDB utilization, and 85% Docker VM disk utilization; exact thresholds may be tuned from measured behavior.

• If a deployment wave exceeds its budget, stop the wave, reconcile NET-004, and either tune, reschedule, reduce retention, increase Docker allocation within host limits, or defer the application.

• Replace estimates in this chapter with observed baselines and retain the prior document version before changing resource decisions.

14.7 Source Baseline¶

Compose patterns and ports were derived from current upstream documentation and repositories as of August 14, 2026. Before deployment, confirm the current stable image tag and any migration notice at the official source.

• LinuxServer.io container documentation: https://docs.linuxserver.io/images/

• Seerr: https://github.com/seerr-team/seerr and https://docs.seerr.dev/

• Cleanuparr: https://github.com/Cleanuparr/Cleanuparr

• Recyclarr: https://github.com/recyclarr/recyclarr and https://recyclarr.dev/

• Maintainerr: https://github.com/Maintainerr/Maintainerr and https://docs.maintainerr.info/

• Uptime Kuma: https://github.com/louislam/uptime-kuma

• WUD: https://github.com/getwud/wud and https://getwud.github.io/wud/

• Prometheus/cAdvisor: https://prometheus.io/docs/guides/cadvisor/

• Grafana: https://grafana.com/docs/grafana/latest/setup-grafana/installation/docker/

• Scrutiny: https://github.com/AnalogJ/scrutiny

Appendix A - Ports and Endpoints¶

Appendix B - Recovery Checklist¶

Appendix C - Revision History¶

Related Documentation¶

Related¶

• Related audit: NET-AUD-002

Document Control¶