Documentation

These figures are derived from the component profile, not measured against a customer estate. They are a defensible starting point for procurement. Validate the storage assumptions below against a pilot before committing to a large deployment, because two of them — how much cryptographic material an average host holds, and how often it changes — vary by more than an order of magnitude between estates.

Pick a tier

Choose by host count and material count, not by licensed user count. Console users are a minor contributor to sizing; the inventory is not.

Tier 0 — Proof of concept

Property	Specification
Scope	Up to 500 hosts, 100,000 materials, 3 concurrent users
Topology	Single node, all services co-resident
CPU	4 vCPU (x86-64, 2.5 GHz or better)
Memory	16 GB
Storage	150 GB SSD
Network	1 Gbps
High availability	None

Evaluation and functional validation only. Not supported for production.

Tier 1 — Small production

Property	Specification
Scope	Up to 2,000 hosts, 500,000 materials, 10 concurrent users
Topology	Single node, all services co-resident
CPU	8 vCPU
Memory	32 GB
Storage	300 GB SSD, 3,000 sustained IOPS or better
Network	1 Gbps
High availability	Cold standby node, restore from backup
Recovery objectives	4 hours to recover, 24 hours of data at risk

Tier 2 — Medium production

Property	Specification
Scope	Up to 10,000 hosts, 2,000,000 materials, 25 concurrent users
Topology	Two nodes — application and database
Application node	16 vCPU, 32 GB RAM, 200 GB SSD
Database node	8 vCPU, 32 GB RAM, 500 GB NVMe, 10,000 sustained IOPS
Network	1 Gbps between nodes, under 1 ms latency
High availability	Warm standby application node; database replica set optional
Recovery objectives	2 hours to recover, 4 hours of data at risk

This is the reference configuration against which the platform's performance targets are stated.

Tier 3 — Large production

Property	Specification
Scope	Up to 50,000 hosts, 10,000,000 materials, 100 concurrent users
Topology	Role-separated, database replica set
Application nodes	2 nodes, each 16 vCPU, 64 GB RAM, 200 GB SSD, behind a load balancer
Database nodes	3 nodes, each 16 vCPU, 64 GB RAM, 1 TB NVMe, 20,000 sustained IOPS
Identity node	4 vCPU, 8 GB RAM, 100 GB SSD
Observability node	8 vCPU, 16 GB RAM, 500 GB SSD
Network	10 Gbps between nodes, under 1 ms latency
High availability	Active-active application tier, automatic database failover
Recovery objectives	1 hour to recover, 1 hour of data at risk

Tier 4 — Enterprise

Above 50,000 hosts or 10,000,000 materials, size from a capacity study against the actual estate rather than from a table. The starting envelope is a horizontally scaled application tier of three or more nodes, a sharded database, and regional collectors. See HA and Scaling for the topology.

Per-service resource reservations

The inputs behind the tier table. Use these when packing services onto nodes yourself, or when running on an orchestrator that wants requests and limits.

Service	vCPU (min / recommended)	Memory (min / recommended)	Local disk
Reverse proxy	0.25 / 1	128 MB / 256 MB	1 GB
Backend API	2 / 4	2 GB / 6 GB	5 GB
Collector	1 / 2	512 MB / 2 GB	5 GB plus certificate cache
Collector worker	1 / 2	512 MB / 2 GB	2 GB
Console	0.25 / 0.5	128 MB / 256 MB	1 GB
Database	2 / 8	4 GB / 32 GB	See the storage model
Identity provider	1 / 2	1.5 GB / 3 GB	5 GB
Message broker	1 / 2	1 GB / 4 GB	20 GB
AI service	2 / 4	2 GB / 6 GB	20 GB
Telemetry collector	0.5 / 1	256 MB / 1 GB	2 GB
Log store	1 / 2	1 GB / 4 GB	See the storage model
Telemetry dashboards	0.5 / 1	512 MB / 1 GB	5 GB
Discovery server	2 / 4	1 GB / 4 GB	10 GB

Three rules that matter more than the numbers:

The database is the dominant component. Provision its memory to hold the working set — at least 1.5 times the combined size of the indexes on the inventory and history collections. Everything else is comfortably sized by the table.
Set the identity provider's heap explicitly. Leaving a JVM to container-default detection on a large node produces a heap far larger than it needs and starves its neighbours.
Declare CPU and memory limits on every service. On a shared node, one service without a limit can starve the rest during an analysis pass.
A self-hosted AI model is additional. Its compute and memory are on top of the AI service row, not included in it.

Storage model

Recalculate for your own estate; do not take the worked example as a default.

Assumptions

Assumption	Default	Why it varies
Materials per host	180 with operating-system trust stores included, 25 without	Scanning trust stores adds roughly 150 certificates per host. This is the single largest driver.
Stored size of one material	6 KB	Includes the encoded certificate and the deployment list.
Stored size of one history entry	2.5 KB
Material-changing revisions per year	1.0	A rescan that finds nothing changed writes no history entry, so this is far lower than the scan count.
Index overhead	40 %
Log retention	30 days

Formulas

materials       = hosts x materials_per_host

inventory_GB    = materials x 6 KB x 1.40 / 1,048,576

history_GB_year = materials x revisions_per_year x 2.5 KB x 1.40 / 1,048,576

deposit_GB      = peak_concurrent_hosts x materials_per_host x 6 KB x 1.5 / 1,048,576

log_GB          = hosts x 50 KB x (30 / scan_interval_days) / 1,048,576  +  15 GB baseline

Provision the database volume at twice the computed steady state, to cover compaction headroom, index rebuild working space and one in-place restore:

db_volume_GB = (inventory_GB + history_GB_year x retained_years + deposit_GB) x 2.0

Worked example

10,000 hosts, trust stores included, one year of history retained, weekly scans, 500 hosts scanning concurrently:

Quantity	Calculation	Result
Materials	10,000 x 180	1,800,000
Inventory	1.8 M x 6 KB x 1.4	14.4 GB
History, one year	1.8 M x 1.0 x 2.5 KB x 1.4	6.0 GB
Deposits in flight	500 x 180 x 6 KB x 1.5	0.8 GB
Database volume to provision	(14.4 + 6.0 + 0.8) x 2.0	about 43 GB
Logs at 30-day retention	10,000 x 50 KB x 4.3 + 15 GB	about 17 GB

At this scale the deployment is not storage-bound. The Tier 2 storage figure is driven by headroom and IOPS, not by capacity. Storage becomes the leading constraint above roughly 20 million materials, or where trust-store certificates are inventoried across a very large estate — at which point read the High Availability and Scaling page rather than simply enlarging the volume.

Storage characteristics

Requirement	Value
Media	SSD or NVMe. Not spinning disk, and not a network file share — neither NFS nor SMB is supported for database files.
IOPS	3,000 sustained at Tier 1, 10,000 at Tier 2, 20,000 per node at Tier 3, measured at a 70/30 read/write mix.
Redundancy	RAID 10 or equivalent, or provider-replicated block storage.
Expansion	Must support online expansion without a service outage.

Headroom and growth

Provision at least 30 per cent CPU and memory headroom at steady state. Discovery is bursty: a full-estate scan and the analysis pass that follows it are the peak, not the average.
Size for the estate you will have in twelve months, not the one you have today. Inventory grows with onboarding; history grows continuously.
Re-measure after the first full-estate scan. That is the first point at which the materials-per-host assumption becomes a measurement rather than an estimate, and it is worth revisiting the model then.

Virtualisation

Requirement	Detail
Platform	x86-64 under VMware vSphere, Hyper-V, KVM, or a major public cloud compute service.
CPU over-commit	Not on the database node.
Memory	Must not be ballooned or swapped on any node.
Time	Synchronised by NTP or the hypervisor, with skew across nodes below one second. History and time-series correctness depend on this.
Architecture	ARM64 is not supported for production.

Target hosts

Requirements on the machines being scanned, not on the platform.

Property	Requirement
Prerequisites	None. The agent is self-contained; no interpreter, runtime or package is installed.
Free disk	250 MB, plus transient space proportional to the corpus for deep filesystem or source-code scans.
Peak memory	512 MB for the default sensor set; up to 1 GB for source-code or large keystore scans.
CPU	One core, priority-constrained so it does not degrade the host's production workload.
Residue	The agent removes its artefacts after results are transmitted. No key material is left on disk.

CBOM Secure

Sizing Guide