External/roboco
1
0
Fork 0
mirror of https://github.com/rennf93/roboco.git synced 2026-08-03 07:23:24 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: document both deploy paths, registry knobs, measured resource usage

Browse Source 
README + deployment guide now show three ways to run RoboCo — pull the
pre-built images (docker-compose.registry.yml), build from source, or the
local-dev flow — instead of only the dev path. Add the ROBOCO_REGISTRY /
ROBOCO_VERSION knobs and the required ROBOCO_ENCRYPTION_KEY (which was
missing) to .env.example, and fix a stale piragi reference there.

usage.md drops the unmeasured per-agent RAM ceiling and records the figures
measured on the live stack: RAM is low and Ollama-dominated, storage is the
real cost (images share the agent-base layer). Idle numbers — peak under an
active task is best read live with docker stats.
This commit is contained in:
Renn F
2026-06-16 20:38:49 +02:00
parent 1dc9e8e47a
commit 4441b23df4
4 changed files with 120 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files
usage.md
+25 -4
View File
@@ -241,10 +241,31 @@ the on-demand Intake and Secretary only run while you're interacting with them.
Steady-state memory is dominated by the standing services (Postgres, Redis,
and especially Ollama with its models loaded), not by the agents.
Storage is the larger footprint: the built (or pulled) image set. The agent
images all share a common base layer, so on disk they cost far less than their
nominal sizes added together. `docker system prune` reclaims old image versions
and stopped agent containers.
Measured at idle on the reference NAS (full stack up, no task running), the
standing services use roughly:
| Service | RAM (idle) |
|---------|------------|
| Ollama (models loaded) | ~2.2 GB |
| Orchestrator | ~150 MB |
| Postgres | ~60 MB |
| Panel | ~35 MB |
| Redis | ~15 MB |
| nginx | ~10 MB |
So the whole standing stack idles around ~2.5 GB, almost all of it Ollama;
the application itself is a few hundred MB. (These are idle figures — peak
memory while agents are actively working will be higher, and is best read
live with `docker stats` while a task is in flight.)
Storage is the larger footprint: the image set. The agent images all build
`FROM` a shared base layer, so on disk they cost far less than their nominal
sizes added together. For reference, the panel image is ~230 MB, the
orchestrator ~0.9 GB, the agent base ~1.1 GB, and each agent image ~1.1 GB
(the frontend dev/QA images are larger, ~1.9 GB, for their browser/Node
toolchain) — but the shared base means the real on-disk total is well below
their sum. `docker system prune` reclaims old image versions, stopped agent
containers, and build cache (typically a few GB).
Monitor with:
```bash