Requirements and sizing

CID222 ships as one virtual appliance and one build. The licence file, not the image, decides which package you run, so sizing is a question about the host and about the components your package adds to it. This page gives the numbers to allocate before you import anything, and says which of them were measured and which were declared.

The problem

Undersizing is the most common cause of a failed evaluation, and it does not fail where you are looking. Every container pulls and starts, the dashboard comes up, and an hour later services are killed one at a time as memory runs out — the console reports 2/10 running with no explanation. The installer's own comments say exactly this, which is why it now checks memory and disk before it downloads anything.

One build, three packages

Starter, Professional and Enterprise are strict supersets of one another. There is only one release image; the .lic file you upload unlocks the package you purchased, so moving up a package is a licence re-issue, never a reinstall.

The exact feature key each tier grants is generated from the code in licence tiers and feature keys. Treat that table as authoritative: the package comparison printed in the customer install guide predates several core keys and does not list compliance, governance or endpoint-agent administration at all, although the code grants them to every tier.

Unlocking a feature key is not the same as installing the component behind it. Three of them — Code Safety, the LLM Risk Analyst and the MCP server — cost real hardware, and two of those run outside the appliance. Every component you add carries its own requirement line, listed in optional services and what each one costs.

What always runs

The base appliance is the set of services that start with no compose profile. Nineteen of them exist in the compose files, they declare 37.63 GB of memory limits between them, and six declare no limit at all — so the declared total is a floor, not a ceiling. The generated per-service breakdown is in services, ports and profiles.

Declared limits are not consumption. The stack was measured on the development server on 2026-09-08, reading anonymous memory out of each container's own cgroup rather than trusting docker stats, which charges a container for page cache it does not need to keep:

The three ONNX detectors — the jailbreak, toxicity and PII guards — are the whole story at idle. Each uvicorn worker loads its own full copy of the model, so UVICORN_WORKERS moves the idle figure more than anything else you can change. The same stack idled at 7.3 GiB on a laptop pinned to one worker per service and at 12.5 GiB on the server running two to four.

Idle is not the number to size on. Under load the stack grows and does not shrink back:

Measured end to end: the same 21 containers that showed 12.53 GiB anonymous in the morning showed 15.25 GiB after one day of OCR and detector load, and none of the 2.7 GiB came back. A box that idles at 6–7 GiB is doing 9–10 GiB the moment documents and images arrive, before page cache.

Baseline per deployment mode

Every mode runs the same container stack — the licence gates features, not containers — so the supported minimum does not move. What moves is the head-room you should buy and the traffic the box has to absorb.

CPU, RAM, disk and network

Each row gives a supported minimum, a recommendation, and what the difference buys.

Text-only work is cheap and image work is not. Two measured contrasts to plan against:

• The jailbreak guard costs about six times the CPU of the toxicity guard per request — 1717 ms against 293 ms on the same texts and the same host — because it truncates at 512 tokens rather than 256. Eight concurrent requests spent 343 CPU-seconds inside 43 seconds of wall clock on a 10-vCPU box.
• OCR concurrency makes throughput worse, not better. Four A4 pages at once took 99 seconds each against 22.3 seconds sequential, and the CPU spent per image rose from 190 to 238 seconds. One request already uses every core, so four only contend. Throughput comes from a CPU cap and a smaller detector input, or from a GPU.

What the GPU buys, and what it does not

A GPU is recommended, never required, and it matters for document, OCR and image-heavy work only. PaddleOCR on an NVIDIA card is roughly 3 to 8 times faster per image. PII, toxicity, jailbreak and injection detection run on ONNX on the CPU, and adding a card does not change their latency. Hallucination detection is a CPU-only build.

Host prerequisites, when you do add one: Linux, an NVIDIA GPU with driver 530 or later, and the NVIDIA Container Toolkit. The GPU paths and their VRAM figures are in optional services and what each one costs.

How storage grows

Container images and model caches are a fixed cost you pay once. What accumulates is evidence: detections, event logs, document analyses and compliance snapshots.

Event logs have shipped retention windows, held per event category:

The security window is 400 days on purpose: a twelve-month observation window plus roughly five weeks of audit lead time, which also clears the six-month statutory floor with margin.

Four tables are surveyed and never swept, whatever the policy says: content detections, document analyses, compliance snapshots and control observations. They are the compliance evidence itself, and deleting them is a human decision rather than a default.

What to do when storage grows:

1. Read the survey first. It tells you which category is actually large before you change a window.
2. Shorten the request and performance windows before you touch security or audit. Those two are the high-volume, low-evidentiary-value categories.
3. Enable enforcement deliberately, once, after you have exported anything you are required to keep. Turning it on deletes everything already past its window.
4. Grow the disk rather than the retention policy where an auditor samples across the full window.

Virtualisation notes

The appliance is a guest, and two hypervisor conveniences turn into incidents under memory pressure.

• Turn the balloon driver off, or pin the guest's memory. This is not theoretical. During a 13-minute OCR measurement — one client, one page at a time — guest free memory fell from 11.0 GB to 7.7 GB, swap in use went from 2 MB to 2.4 GB, load average reached 7.55, and the guest's own total memory dropped from 32.0 GB to 30.4 GB as the hypervisor reclaimed pages from a guest that was already short of them. A ballooned guest swaps, and a swapping detector misses its latency budget rather than failing visibly.
• 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.
• Do not overcommit the host. The appliance's own measured working set grows through the day and never returns; a host sized on the guest's first-hour consumption is oversubscribed by the evening.

Hypervisors

The appliance is delivered as a single .ova file, or as an installer ISO for bare metal and for a virtual machine you build yourself.

The shipped OVA is pre-sized at 32768 MB and 8 vCPU — the supported minimum — so it powers on correctly with no operator arithmetic. Raise it to your recommended profile before the first power-on.

Firmware and boot

The OVF descriptor sets no EFI flag, so a host importing the OVA defaults to BIOS firmware, which is how the image is built and verified. The installer ISO carries both the BIOS and the UEFI boot images of its Ubuntu base and boots either way; its menu offers a UEFI firmware settings entry only when it was itself started in UEFI mode.

Browser

The dashboard is a React single-page application served over HTTPS.

• Serve it over HTTPS. The dashboard sends a Content-Security-Policy: upgrade-insecure-requests header, so a browser opening an appliance by plain HTTP upgrades every asset request to HTTPS. On an ISO-installed appliance, which is HTTPS-only, that works; on a deployment with no HTTPS listener the page renders blank rather than erroring.
• Trust the appliance certificate. A first-boot appliance serves a self-signed certificate and the browser shows a one-time warning. The browser extension and Claude Code refuse an untrusted certificate outright rather than warning.

What the first-boot check actually enforces

An appliance installed from the ISO checks memory and free disk on tty1 before it downloads a single image, and again on every retry boot.

The same first-boot pass also nudges time synchronisation before it contacts the registry, because a wrong clock makes a valid certificate look invalid and the resulting error reads like a network fault.

Limits and known gaps

• The installer's resource check is weaker than the supported minimum. It fails at 6 GB and warns at 15 GB, against a documented floor of 32 GB. It catches the machine that cannot work at all, not the machine that will disappoint you.
• Older CID222 material quotes figures that the measurements do not support. Earlier guides and appliance build notes say the default profile declares about 42 GB of limits across 11 unlimited services and that the stack was measured at about 30 GiB. The figure generated from the current compose files is 37.63 GB across 19 services with 6 unlimited, and the 2026-09-08 cgroup measurement puts the running stack at 12.53 GiB of anonymous memory idle and 15.25 GiB after a day of load. Trust the generated and measured numbers: the 30 GiB figure came from a 2026-07 staging rehearsal that recorded "all services up with head-room on a 62 GiB box", not a per-container measurement. The 32 GB floor still holds — it is head-room for load, not for boot.
• Memory limits are declared for some services and not others. Six services in the default profile declare no limit, so a host running out of memory is not diagnosable from the compose file alone.
• Capacity per user is not published. No throughput or concurrent-user figure has been measured on customer hardware, so the sizing here is a floor for the stack, not a capacity model for your population.
• Several optional components have never been measured. The inline proxy, the user-ID agent and the cost analyser declare no memory limit and were not in the measured container set. Where a figure is missing, optional services and what each one costs says so and says what to measure.
• A GPU cannot be added to a shipped appliance. The GPU paths exist only in a direct install's compose overlays and on separate hosts, which the appliance image does not carry.
• Cloud model providers still require egress. The detection pipeline runs entirely locally, but the Anthropic and Google provider clients dial their vendor cloud with no configurable base URL.

Related tasks

• Optional services and what each one costs — the requirement line for every component a package can add.
• Resource sizing — the measured per-container tables behind this page.
• Network prerequisites — the ports, egress and name resolution to agree with the network team before the virtual machine exists.
• Install on a hypervisor — import the OVA with the right sizing, disk and adapter.