Resource measurements and limits
These are dated observations from specific workloads, not live capacity or worst-case guarantees. Process PSS and Docker working set approximate different parts of memory use; RSS totals double-count shared pages. Do not combine unrelated measurements into a precise host budget.
| Observation | Result | Scope |
|---|---|---|
| Optimized API fresh setup | 76.5–84.1 seconds; 1.90–2.09 GiB sampled peak | Cached images/dependencies; setup plus containers; excludes API/dashboard/browser/agents |
| API unchanged rerun | 12.5 seconds | Same benchmark conditions |
| API retained restart | 37.2 seconds | Same benchmark conditions |
| Warm API/dashboard pair before final integration | About 7.0 GiB | App PSS plus container working set; not current usage |
| Loaded shared browser | About 1.8 GiB PSS | Browser/display/viewer/MCP stack; shared, not per task |
| Appliance first / cached second / warm restart | 54.3 / 15.7 / 2.2 seconds | Recorded search-engine workload |
| Appliance idle runtime | About 257 MiB | One worktree, process PSS plus Docker working set |
| Two appliance build/test workloads | 2.41 GiB sampled combined peak | Includes their runtimes/test stacks; excludes unrelated apps and agents |
Early CDC bulk snapshots caused multi-GiB Pub/Sub growth. The reviewed worktree lifecycle uses ordered initialization and streaming CDC to avoid that replay spike. It does not backfill historical analytics. Dashboard type/lint workers were another major consumer; only one preview is needed.
Appliance container ceilings of 2 GiB / 256 MiB / 512 MiB for DB/Redis/RabbitMQ are limits, not reservations or expected idle use. Four Cargo jobs and a build lock bound concurrency; copied executables preserve task isolation.
Six full-stack tasks at 3 GiB each was an initial guess and is not supported. Measure actual work, including agents and shared services, before raising concurrency. Resource triage.