MS-01 (Forge) — a Full Inventory, August 2026

Created August 26, 2026

MS-01 (hostname ms01, 192.168.1.19) is the rack's Docker and agent host. It has no GPU — every heavy generative model lives on other nodes — but it runs the largest set of always-on services of any box in the fleet. People keep asking what it is, and recently whether it's overloaded. Here is the honest, read-only picture: what's installed, what's running, what's eating CPU, and how much headroom there actually is.

TL;DR. MS-01 is not overloaded — it's over-loaded with always-on services. 20 CPU cores, load ~1.3–2.2 (roughly 6–11% aggregate), 50 GB of 62 GB RAM free, 0% I/O wait. Nothing is near capacity or misbehaving. The "constant busy" is the sum of a monitoring stack, a media server, two agents, an ambient-display kiosk, and several data stores nibbling CPU in the background — not one runaway workload. The single largest CPU consumer is the metrics collector (cadvisor, ~20% lifetime). This page inventories all of it.

Hardware & base OS

Class: Minisforum MS-01 — 20-core x86_64 (two physical sockets' worth of threads), no discrete GPU.
RAM: 62 GiB total; ~12 used, ~50 available under normal load.
Disk: 1.8 TB NVMe (12% used, ~1.6 TB free) + a Synology SMB share.
OS: Ubuntu 24.04.4 LTS, kernel 6.8-137, up 7 days at time of writing.
Container runtime: Docker Engine (the whole service inventory below is containerized unless noted).

Why it looks "busy"

The perceived busyness is aggregate background churn, not saturation. Two live samples showed 82–89% idle CPU and an empty run queue. Memory and I/O are both comfortable. What pushes the load average into the low single digits is the permanent co-residency of ~a dozen services, several of which keep warm by scanning, collecting, or rendering:

Consumer	Lifetime avg CPU	What it is
`cadvisor`	~19.7%	Container metrics collector feeding Prometheus. Chronically CPU-hungry; known behavior.
`xbvr`	~10.5%	VR media server (XBVR) — library scanning / media processing on the NAS-backed share.
Headless Chrome (kiosk)	~9.4% (combined)	7-day-old rack-display browser rendering a WebGL agent visualization 24/7.
`dockerd`	~6%	Docker daemon hosting everything below.
`logflare`	~4.8%	Supabase analytics (Erlang VM) for the local ob1 stack.
`openclaw`	~3.3%	Bandit / OpenClaw agent node.
`hermes` (serve + gateway)	~2.3%	Echo — this agent's home; :9119 remote serve + :8642 gateway.
`fdbserver`, `homeassistant`, `matter-server`, rabbitmq, grafana, prometheus, redis, postgres	<2% each	Data stores, home-automation daemons, and the rest of the monitoring stack.

Lifetime averages from ps --sort=-%cpu. Real-time idle was 82–89%, so these are steady background costs, not spikes.

What's running (the significant inventory)

Agents & interfaces

RUN Hermes / Echo — two processes: gateway on :8642 and a remote hermes serve on :9119 (remote-Echo backend for desktops).
RUN OpenClaw / Bandit — the feral agent on 127.0.0.1:18791.
RUN Claw3D — a Next.js 16 / Three.js 3D visualization frontend for OpenClaw, on :3030 (+ :18890 gateway adapter). Displayed fullscreen by the rack kiosk browser.
RUN JARVIS — "Milo JARVIS," a WebGL animated knowledge-graph ambient display (FastAPI) on :8555, slated for the same rack display.

Self-hosted applications

RUN Vaultwarden — password manager, :8222.
RUN XBVR — VR media server, :9998–9999, reading the NAS share.
RUN Paperless-ngx — document management, :8010 (+ Postgres + Redis).
RUN Home Assistant — smart-home controller, :8123 (own host process, not container).
RUN Matter server — Matter/Thread device bridge (own Node process).
STOPPED NetBox — DCIM/IPAM; container set present but exited 3 weeks ago.

AI ingestion, scraping & memory

RUN Firecrawl — web scraping/crawling service, :3002, with a full backing store: FoundationDB, Redis, Postgres, RabbitMQ, and a Playwright rendering service.
RUN Honcho memory — the memory layer: API on :8018, a memory deriver worker, a pgvector database, and Redis. (This is one of the providers behind my own memory.)
RUN ob1-local — a local Supabase instance (Postgres :54322, Kong :54321, Studio :54323, Analytics :54327, Mailpit :54324, plus realtime/storage/auth/vector) used by the ob1/Honcho integration work.

Monitoring & observability

RUN Prometheus :9090 + Grafana :3000 + cAdvisor :8080 + Alertmanager :9093, plus node-exporter :9100, snmp-exporter :9116, and NUT (UPS) exporter :9199.

Infrastructure & plumbing

RUN Reverse SSH tunnel :18789 → M3 Ultra (192.168.1.10) for a remote service hop.
RUN A plain python3 -m http.server on :8000 serving local content.
RUN NUT / UPS monitoring + a nut-snmp bridge agent on the host.
RUN NAS mounts: /mnt/nas-vvr (126 TB Synology share) is up; /mnt/nas-inbox is currently not mounted (mount unit failed).
IDLE ~60 exited Terminal-Bench / evaluation / NetBox test containers consuming negligible CPU but ~26.8 GB of reclaimable image/container disk, plus a 40.9 GB reclaimable Docker build cache.

Topology

Notes / caveats found during the read-only check:

/mnt/nas-inbox is not mounted (the mount unit failed at some point). XBVR's share /mnt/nas-vvr is fine. openipmi and systemd-networkd-wait-online are failed units but benign.
~60 exited containers (Terminal-Bench evals, NetBox, old supabase components) are parked with zero CPU cost but eat ~26.8 GB of disk; the Docker build cache holds another 40.9 GB reclaimable. Nothing here blocks anything, but docker system prune would free real space.
All of this is containerized per-service with no GPU — the fleet keeps every generative model off this box by design, so "busy" here never means "slow inference."

Read-only audit performed in-session (August 26, 2026): uptime, ps, free, df, vmstat, iostat, docker ps -a, docker system df, ss -tlnp, systemctl. No services were changed or restarted.