Resource sizing
What the declared container memory limits add up to, what each optional compose profile adds on top, and the two places a GPU changes anything.
- Version: 0.4
- Role: admin_user
- Type: reference
The per-service numbers are in services, ports and profiles, which is generated from the compose files. This page is the arithmetic on top of them: what they total, what an optional profile adds, and what a GPU does and does not change. For the host you should buy, start at requirements and sizing.
What the default stack declares
| Measure | Value |
|---|---|
| Services that start with no profile | 19 |
| Memory limits those services declare, in total | 37.63 GB |
| Of those services, how many declare no limit at all | 6 |
| Full stack measured running | ~30 GiB |
| Supported host minimum | 32 GB RAM, 8 vCPU, 100 GB disk |
The six services with no declared limit are the reverse proxy, the dashboard, the gateway, the database and the cache, plus the host reconfigure agent. They are unbounded because nothing constrains them, not by intent, which is why the declared total is a floor rather than a ceiling.
Warning
Undersizing does not fail where you are looking. Every container pulls and starts, the dashboard comes up, and services are killed one at a time an hour later as memory runs out. Size the host before you import anything.
What each optional profile adds
Added to the default stack, not instead of it. A dash means the profile's services declare no memory limit, so budget for them by measurement rather than by the compose file.
| Profile | Declared memory it adds | Also needs |
|---|---|---|
llm-analyst | 4 GB (risk-analyst 3 GB, mcp-server 1 GB) | A model engine to talk to — either the llm profile on this host or a separate GPU machine |
routing | 1 GB (cost-analyzer) | — |
gpu | 16 GB (ocr-service-gpu) | An NVIDIA GPU with 16–24 GB of VRAM |
inline-proxy | — | Client browsers configured to use it, and its CA trusted on the fleet |
userid-agent | — | Reachability to a domain controller |
llm | — | A GPU; this is the analyst's model engine, and the practical case is a machine of its own |
tools, ldap-test, mailtest | — | Development hosts only |
Where a GPU changes something
A GPU is recommended, never required, and only for document, OCR and image-heavy work. There are three GPU paths and they are independent of each other.
| Path | What it is | Notes |
|---|---|---|
docker-compose.gpu.yml | Rebuilds the default ocr-service to run PaddleOCR on CUDA | Measured 3–8× faster per image than the CPU build. Never used on an appliance, which stays CPU-only |
The gpu profile's ocr-service-gpu | A 4-billion-parameter transformer OCR engine on CUDA 12.1 | Takes over the same container name as the CPU ocr-service, so the two are mutually exclusive. 16–24 GB of VRAM is realistic; below 16 GB it quantises itself to 4-bit |
| The analyst model engine | The local model the LLM Risk Analyst reasons with | Runs on a separate GPU machine in the supported topology, not on the appliance |
Nothing else in the stack uses a GPU. PII, toxicity, jailbreak and injection detection run on ONNX on the CPU, and adding a card does not change their latency.
Notes
- Disk grows with retention, not with traffic peaks. Detections, event logs and compliance evidence are what accumulate; the container images and model caches are a fixed cost you pay once.
- Swap is a margin for brief model spikes, not a substitute for memory. 8 GB is enough on a correctly sized host, and no amount of it rescues a host below the 32 GB floor.
- The shipped appliance image is pre-sized at the supported minimum — 32 GB RAM and 8 vCPU — so it powers on without operator arithmetic. Raise it to the recommended profile for your package before you put load on it.
Related
- Requirements and sizing — the host to provision, per package.
- Services, ports and profiles — the generated per-service table.
- Compose profiles and CLI — how a profile is started.
Last updated on