System Requirements
This page specifies the hardware, operating system, and storage requirements for a ScreenStop deployment. It covers two components:
- Management Server — the self-hosted Dashboard (Docker), one per deployment.
- Endpoints — the workstations running the ScreenStop agent.
Management Server (Dashboard)
The Dashboard is a single, lightweight container stack: a Python/FastAPI application with an embedded SQLite database, fronted by an nginx reverse proxy for TLS. There is no external database to provision and no GPU required — the optional AI-analysis feature calls an LLM endpoint of your choice (a local model host or an approved API), so the model never runs on this server.
Compute
Compute requirements are independent of the number of endpoints — the server load is dominated by periodic, low-frequency check-ins. Storage (see below) is the only dimension that scales.
| Deployment size | OCPU | RAM | Notes |
|---|---|---|---|
| Up to ~100 endpoints | 2 | 8 GB | Recommended baseline |
| Minimum (pilot / small) | 1 | 4 GB | Functional floor |
| 500–1000 endpoints | 4 | 16 GB | Headroom for concurrent sync + frame I/O |
OCPU
On Oracle Cloud Infrastructure, 1 OCPU = 1 physical core (2 vCPUs on x86). The figures above are OCPU.
Operating System & Software
- OS: Linux, x86_64 — Oracle Linux 8 or 9, or Ubuntu 22.04 LTS
- Docker Engine 20.10+
- Docker Compose v2
- TLS certificate + private key for the nginx front end
Storage
Storage is the dimension that scales with your deployment. The database itself is small and self-pruning; stored images dominate. Two optional features generate images:
| Feature | What it stores | Relative cost |
|---|---|---|
Event images (capture_mode) |
One snapshot per detection event | Low — tens of MB per endpoint per month |
| Visual log | A periodic audit snapshot while a user is present (default: every 10 s) | High — this dominates total storage |
Both are off by default. If neither is enabled, the server stores only event metadata (megabytes), and a small base volume is sufficient.
Storage sizing formula
| Symbol | Meaning | Planning value |
|---|---|---|
| X | Number of endpoints | your deployment |
| Y | Retention — days of image history to keep | your compliance policy |
| Z | Event images enabled? (1 = yes, 0 = no) |
— |
| A | Visual log enabled? (1 = yes, 0 = no) |
— |
| E | Detection events per endpoint per day | ~30 (typical) |
| H | Active hours per endpoint per day (user present) | 8 |
| I | Visual-log interval, in seconds | 10 (default) |
| F | Average image size | 0.2 MB |
| Base | OS + Docker images + database | ~20 GB |
With the default visual-log interval, the visual log produces
H × 3600 ÷ I = 8 × 3600 ÷ 10 ≈ 2,880 images per endpoint per day — roughly 100× the
volume of event images. Whether the visual log is enabled is the single decision that
sets the order of magnitude of your storage.
Worked examples
Assumes 100 endpoints, 30-day retention, F = 0.2 MB:
| Event images | Visual log | Per endpoint/day | Total storage |
|---|---|---|---|
| Off | Off | ~0 | ~20 GB (base only) |
| On | Off | ~6 MB | ~38 GB |
| Off | On | ~576 MB | ~1.7 TB |
| On | On | ~582 MB | ~1.7 TB |
Controlling storage
Storage scales linearly with retention (Y) and with the number of endpoints (X).
When the visual log is required, two levers reduce its footprint:
- Increase the interval
I. Raising it from 10 s to 60 s cuts visual-log storage ~6× (2,880 → 480 images per endpoint per day). - Shorten retention
Y. Storage is directly proportional to the number of days kept.
Retention must be enforced
Image files are removed by a retention/cleanup job at your chosen horizon (Y). If image
capture is enabled, ensure the cleanup is scheduled — otherwise the image store grows
without bound and will eventually fill the volume. Provision the block volume from the
formula above with headroom, and monitor disk usage.
Endpoints (Workstations)
The agent runs on standard corporate workstation hardware. Detection runs on the CPU; no GPU is required.
| Requirement | macOS | Windows |
|---|---|---|
| OS | macOS 11.0 (Big Sur) or later | Windows 10 or 11 (64-bit) |
| Architecture | Intel or Apple Silicon | x64 |
| Camera | Built-in or external webcam (required) | Built-in or external webcam (required) |
| Hardware | Any modern workstation (dual-core+, 4 GB RAM) | Any modern workstation (dual-core+, 4 GB RAM) |
The agent reports to the Management Server over HTTPS. Image delivery from endpoints is
controlled per-station by capture_mode (see the install guides), which corresponds to the
event images factor (Z) in the storage formula above.
Network
- Endpoints reach the Management Server over HTTPS (443).
- The Management Server is self-hosted within your tenancy; no ScreenStop cloud dependency.
- Optional AI analysis: outbound access only to the LLM endpoint you configure (a local model host keeps all data within your tenancy).