Services and data
Where each service lives, what is running, and where its data goes.
Active services
| Service | Source of truth | Runtime | Data / access |
|---|---|---|---|
| CLIProxyAPI + dashboard | /home/yvm/codes/cliproxyapi-dashboard | Dashboard, API, Postgres, Docker socket proxy | Named Docker volumes on SSD; dashboard :3001, API :8317 |
| YT-YVMX | /home/yvm/yt-yvmx | Backend healthy; frontend container is created but not running | ./data and downloads on SSD; audio bind is on protected HDD |
| YVMX homepage | /home/yvm/cc/yvmx-homepage | yvmx-homepage | Loopback :8787; stateless image build |
| Beszel | /home/yvm/beszel | Server + agent | Loopback :8090; agent data under the project directory |
| Dograh | /home/yvm/dograh | Tunnel only; app stack exited | Named Docker volumes exist; review before cleanup |
Important data rules
- Keep databases and application state in named volumes or explicit SSD project directories.
- Keep media and long-lived downloads on the HDD path already used by YT-YVMX.
- Never use
docker compose down -von a stateful project. - Never publish an internal database, Docker socket proxy, or management API just to make the UI work.
Resource limits already present
The YT-YVMX Compose file limits the backend to 2 CPUs / 2G and the frontend to 0.5 CPU / 128M. The production CLIProxyAPI Compose file has limits for its services; the active local Compose file does not. Add local limits only after checking real peak usage.
Stopped is not deleted
Several old stacks have exited containers but still have images, volumes, and build cache. The current state is untidy, but it is recoverable. Cleanup is staged in the SSD cleanup plan instead of being mixed into service startup.