ORTUS CHEQIT System Requirements And Sizing

Purpose

This document gives practical host sizing guidance for ORTUS CHEQIT installed deployments. Use it for pilot planning, customer documentation, proposals, and slide decks.

Sizing depends on camera count, connector type, detector cadence, alert volume, retention policy, update retention, and whether the instance is standalone, primary, leaf, or HA standby. Treat the numbers below as starting points and validate them during the customer pilot.

Supported Deployment Platform

Recommended production host:

Linux x86_64 server or VM.
Ubuntu Server 22.04 LTS or 24.04 LTS, or another systemd-based Linux distribution validated by ORTUS.
systemd for service management and signed update orchestration.
SSD or NVMe-backed persistent storage.
Reliable time synchronisation.
HTTPS/TLS for browser access.
Network reachability to the required VMS/camera networks.
SMTP reachability if email 2FA or email notifications are used.
ORTUS licensing/update reachability for online deployments, or offline .key activation and signed offline update bundles for air-gapped deployments.

Windows installer support is not included in this release.

Recommended Sizing Tiers

Deployment profile	Typical use	CPU	RAM	Storage	Notes
Evaluation / small standalone	Lab, pilot, or small site up to 25-50 cameras	4 vCPU	8 GB	100 GB SSD	Suitable for initial validation and light retention.
Standard site / leaf	Site or leaf node up to about 250 cameras	8 vCPU	16 GB	250 GB SSD/NVMe	Recommended baseline for production sites.
Large site / primary	Larger local site or primary aggregating several leaves, up to about 1,000 local/managed cameras	16 vCPU	32 GB	500 GB-1 TB NVMe	Use NVMe when alert and artifact volume is high.
Enterprise federated primary	Metadata-first aggregation for many leaves, with a design target up to 10,000 cameras across the estate	16-32 vCPU	64 GB	1-2 TB NVMe	Leaves do the site-local processing; primary aggregates inventory, alerts, licensing, users, settings, and updates. Validate with the customer's topology.
HA standby	Warm standby for any primary profile	Same as active primary	Same as active primary	Same as active primary	Do not undersize standby nodes; after failover they become the active primary.

For federated systems, size each leaf for its local camera count and detector workload. Size the primary for aggregated metadata, alert volume, customer portal/admin activity, update relay, and HA replication rather than for decoding every camera centrally.

Lab Baseline Measurement

The current ORTUS lab deployment was measured on a local Intel NUC-style host:

Item	Measurement
Host CPU	Intel Core i7-1260P, 16 logical CPUs
Host memory	30 GB RAM
Root filesystem	913 GB total
CHEQIT service resident memory	about 714 MB
CHEQIT service peak memory during measured uptime	about 1.0 GB
CHEQIT service CPU time	about 16.6 seconds over about 86 minutes
CHEQIT service task count	31
Installed runtime footprint	about 387 MB under `/opt/ortus-cheqit`
SQLite database	about 190 MB
Database contents	4 cameras, 4,529 alerts, 45,937 alert occurrences, 821 audit events
Evidence/artifact state	about 7.1 GB, about 301,000 files
Update staging/backups	about 8.8 GB after repeated update rehearsals
Total state directory	about 17 GB

Important interpretation:

This snapshot is a useful lower-bound runtime footprint for the current installed service, loaded model, database, UI, and retained state.
The measured instance was activation-locked at the time of sampling, so the CPU and memory numbers are not a peak active-monitoring benchmark.
Separate simulator and FFmpeg processes running on the lab host are not part of the CHEQIT service footprint. Test stream generators can add significant CPU and memory and should be sized separately.

Storage Planning

Storage is usually driven by retained artifacts, update staging/backups, and customer retention policy rather than by the application binary.

Plan storage with these components:

Component	Planning guidance
Application runtime	Reserve 1 GB. The measured installed runtime is about 0.4 GB, including UI and model files.
Database	Start with 1-5 GB for small/standard deployments. Increase for high alert volume, long retention, and large federated metadata.
Evidence and long-exposure artifacts	Dominant variable. Start with 0.25-1 GB per camera per year for hourly low-resolution baselines and compact quality artifacts, then increase for higher cadence, longer retention, or heavier evidence capture.
Update staging and rollback	Reserve at least 3-5 times the signed release archive size plus current install size. With current Linux archives around 350 MB, reserve 2-5 GB minimum.
Support bundles and exports	Reserve operational headroom for temporary support bundles, diagnostics, and customer exports.
Logs and maps	Usually small, but large map image uploads and verbose troubleshooting logs should be monitored.

Keep at least 20% free disk space. Low free space can block updates, support bundle generation, artifact writes, and SQLite maintenance.

Artifact Sizing Notes

The lab artifact store is about 7.1 GB for about 301,000 files, with most files coming from retained long-exposure and detector artifacts. The average artifact size in that snapshot is roughly 24 KB, but real deployments vary by detector, image dimensions, cadence, and retention.

The default long-exposure cadence is hourly. At one retained compact artifact per camera per hour, a rough floor is:

24 KB * 24 hours * 365 days = about 210 MB per camera per year

Use a higher planning value when retaining multiple artifact types per camera, storing alert evidence for longer periods, running higher-frequency checks, or operating in environments with frequent degradation events.

CPU And Memory Planning

CHEQIT is designed around VMS-first monitoring and bounded work queues rather than an unbounded live stream per camera. This keeps scaling predictable, but active detector load still depends on:

number of cameras,
snapshot/check cadence,
enabled detector and alert-type entitlements,
connector type and VMS responsiveness,
local visual model use,
alert and occurrence volume,
federation role.

Use the sizing tiers above as the starting point. Increase CPU and memory when:

the site runs many visual checks at high cadence,
many cameras are unstable and generating repeated occurrences,
the instance is a primary aggregating many leaves,
the host also runs VMS, database, simulator, or other services,
update, backup, support-bundle, or export jobs run during monitoring windows.

Network Planning

Required network paths depend on deployment mode:

Path	Requirement
Browser to CHEQIT	HTTPS access to the active standalone/primary/leaf node.
CHEQIT to VMS/cameras	Low-latency LAN/VPN access to VMS APIs and camera streams/snapshots as required by the connector.
CHEQIT to ORTUS licensing	Required for online activation and online licence refresh. Offline `.key` activation is available for air-gapped deployments.
CHEQIT to ORTUS updates	Required for online update checks/downloads. Offline signed update bundles are available for air-gapped deployments.
CHEQIT to SMTP	Required for email 2FA and alert notifications.
Federated leaf to primary	Outbound HTTPS from leaf to primary. The primary does not initiate inbound connections to leaves.
HA standby to primary	Outbound sync from standby to active primary, plus browser access through DNS/VIP/load balancer or cached endpoint fallback.

For production HA, use a stable DNS name, VIP, or load balancer in front of the active primary where possible. CHEQIT's browser endpoint cache and service-worker fallback improve resilience after the app has loaded once, but they are not a substitute for a stable first-contact address.

SQLite And Filesystem Guidance

CHEQIT stores local state in SQLite. For this release:

Use local SSD/NVMe storage.
Avoid network filesystems for the live database.
Keep the database, WAL, artifacts, and update staging on reliable persistent storage.
Back up using the documented systemd runbook, especially on hosts using systemd DynamicUser.
Keep enough free space for WAL growth, updates, rollback, and support bundles.

SQLite is appropriate for standalone and leaf deployments and for the current primary metadata aggregation model. Very large enterprise deployments should be validated with the real customer camera mix, retention policy, alert volume, and federation topology before final hardware commitment.

Slide-Ready Summary

Use this concise version in commercial or architecture slides:

Small site or pilot: 4 vCPU, 8 GB RAM, 100 GB SSD.
Standard production site: 8 vCPU, 16 GB RAM, 250 GB SSD/NVMe.
Large site or primary: 16 vCPU, 32 GB RAM, 500 GB-1 TB NVMe.
Enterprise federated primary: 16-32 vCPU, 64 GB RAM, 1-2 TB NVMe, with leaves sized per site.
HA standby: match the active primary.
Storage driver: retained evidence/artifacts and update rollback space, not the application binary.
Keep 20% disk free.
Use local SSD/NVMe; avoid network filesystems for the live SQLite database.
Air-gapped deployments use offline licence .key files and signed offline update bundles.

Sizing Validation Checklist

Before confirming production sizing, validate:

camera count per site and total estate,
VMS connector type and API responsiveness,
detector and alert-type entitlements,
monitoring cadence,
evidence/artifact retention policy,
alert volume during normal and degraded periods,
update and backup retention,
federation/HA topology,
SMTP, licensing, update, and support-bundle network paths,
expected growth over the contract period.