Performance and energy

Baseline

The SSD is 56% full, with roughly 99G free. Docker reported:

The host snapshot showed 10 running containers. A one-shot docker stats sample was quiet: most containers were near 0% CPU; the YT backend was about 0.21% and the tunnel processes were below 0.5%. This is a baseline, not a power measurement.

Improvement order

1. Remove accidental exposure

Review 0.0.0.0:8317 (CLIProxyAPI management/API), 0.0.0.0:3001 (dashboard), and 0.0.0.0:2000 (tunnel metrics). Bind to loopback or a trusted LAN interface when public access is not required. This improves security and avoids needless listeners.

2. Stop unused workloads

Dograh’s application services, Immich, Glance, Plex, Pyload, and older HOLEN/APK stacks are currently stopped or partial. Keep their data, but remove only exact stopped containers after ownership is confirmed. Stopped containers do not consume CPU; deleting them is a cleanliness/storage action, not an energy fix.

3. Reclaim build cache first

Build cache is the safest large SSD candidate because it is reproducible, but pruning it makes the next build slower. Do it during a maintenance window and keep volumes untouched.

4. Make idle services on-demand

Keep Dograh, YT-YVMX frontend, and tunnel profiles off unless needed. Review whether host Nginx, MySQL, Samba, xrdp, and the desktop session are required on a headless server before disabling anything.

5. Add limits where missing

The active local CLIProxyAPI Compose file lacks the CPU/memory limits present in the production file. Measure peak memory and request latency first, then add conservative limits to prevent noisy-neighbor behavior.

What not to optimize blindly

• Do not move HDD media to the SSD for speed; it violates the storage boundary and increases SSD wear.
• Do not prune Docker volumes globally; volume names do not reveal whether data is disposable.
• Do not disable Samba, MySQL, Nginx, SSH, Tailscale, or tunnels until their consumers are mapped.