System requirements

Sizing and platform requirements for on-premise, Azure, AWS and GCP installations

TestingOps On-Premise is one application container plus PostgreSQL. The test runs are executed by the RunningOps engine — the cloud service or an engine installed in your network — so the sizing below covers the TestingOps application only. Engine hosts (device farms, browser workers) are sized separately (execution engine).

Sizing tiers

	Pilot	Standard	Large
Who	up to 10 users, 1–3 projects, ≤ 500 runs/month	up to 50 users, ≤ 20 projects, ≤ 5 000 runs/month	50+ users, many customers/business units, 5 000+ runs/month
vCPU	4	8	16
Memory	8 GB (16 GB recommended)	16 GB	32 GB
System disk	60 GB SSD	100 GB SSD	100 GB SSD
Data disk (`TESTINGOPS_DATA_DIR`)	100 GB SSD	250 GB SSD, 3 000 IOPS	500 GB+ SSD, 3 000+ IOPS, or S3-compatible object storage for evidence
PostgreSQL	bundled (same VM)	bundled or managed, 2 vCPU / 8 GB, 100 GB	managed, 4 vCPU / 16 GB, 200 GB, PITR backups

What drives the numbers:

Memory — AI analysis of runs, knowledge-graph queries (pgvector) and catalogue loading at start-up. 8 GB works for a pilot; under 8 GB the first start can take minutes and analysis jobs queue up.
Disk growth — run evidence (screenshots ≈ 150 KB per step, video 5–20 MB per run), uploads and knowledge documents. Plan 10–20 GB per 1 000 runs per month; retention per company is configurable and old evidence is pruned automatically.
CPU — mostly idle; peaks during bulk case generation and report building. Both x86_64 and arm64 images are published; arm64 (Graviton, Ampere) is 20–40 % cheaper for the same throughput.
Shared memory — browser-based sessions inside the app need /dev/shm of 1 GB (set in the kit's compose file and the Helm chart).

Software

Component	Requirement
Operating system	Ubuntu 22.04 / 24.04 LTS, Debian 12, RHEL 9 / Rocky 9 / AlmaLinux 9 (x86_64 or arm64)
Container runtime	Docker Engine 24+ with Docker Compose v2, or Kubernetes 1.27+ (Helm 3)
PostgreSQL	15, 16 or 17 with the pgvector extension (`CREATE EXTENSION vector`). Bundled image: PostgreSQL 17 + pgvector
Object storage (optional)	Any S3-compatible endpoint (AWS S3, MinIO, Ceph RGW, GCS interoperability). Default is the local data disk
Time	NTP-synchronised clock — license validity, session tokens and run timestamps depend on it
TLS certificate	Public CA, corporate CA or Let's Encrypt (automatic when the host name resolves publicly)
SMTP relay (optional)	For invitations and password resets; port 587 STARTTLS or 465
User browsers	Current and previous major version of Chrome, Edge, Firefox, Safari

Network

Inbound:

Port	From	Purpose
443 (80 redirect)	users, CI systems, webhooks from trackers	Web UI and API
22	administrators	Server management (not used by the product)

Outbound (HTTPS, port 443) — allow-list on a corporate proxy:

Destination	Purpose	Optional?
TestingOps image registry	Install and upgrade	Needed at install/upgrade time
Model provider — `api.anthropic.com`, `api.openai.com`, or your internal OpenAI-compatible endpoint	Case generation, run analysis, assistants	At least one
`runningops.ai` (or your on-premise engine address)	Test execution	Unless manual execution only
Trackers — Jira/Confluence Cloud, GitHub, GitLab, Azure DevOps, Linear…	Knowledge sources and defect sync	Per integration
SMTP relay	E-mail	Optional

No inbound connection from the internet is required: integrations and the engine are called from the installation. The engine must reach the applications under test; those applications must allow the engine's egress address through WAF/bot protection.

On-premise (data centre / private cloud)

One VM per tier above on VMware vSphere, Hyper-V, Proxmox or KVM. No nested virtualisation is needed by the application.
Data disk on SSD-backed storage; snapshot-capable storage simplifies backups (backup.sh still runs for a consistent database dump).
Corporate proxy: set HTTPS_PROXY in env.list; mount the root CA (HTTPS).
Air-gapped sites: an offline bundle (images as a tar archive, kit, checksums) is available on request; the licence is a file, no call-home is made.
Kubernetes on-premise (OpenShift, Rancher, Tanzu): a StorageClass that can re-attach volumes on another node (Ceph, NFS, vSAN) — local-path storage pins the pod to a node (Helm).

AWS

Tier	Compute	Storage	Database	Evidence storage
Pilot	`t4g.xlarge` (arm64, 4 vCPU / 16 GB) or `t3.xlarge`	gp3 100 GB	bundled	local disk
Standard	`m7g.2xlarge` / `t4g.2xlarge` (8 vCPU / 32 GB) or `m6i.2xlarge`	gp3 250 GB, 3 000 IOPS	RDS for PostgreSQL 16/17, `db.m7g.large`, Multi-AZ, pgvector available	S3 bucket in the same region
Large	`m7g.4xlarge` (16 vCPU / 64 GB)	gp3 500 GB	Aurora PostgreSQL 16, `db.r7g.large`+, PITR	S3 + lifecycle rule for old evidence

Notes: t4g/t3 burstable instances suit pilots; move to m family when CPU credits run out under bulk generation. Security group: 443 from your users (or ALB), 22 from a bastion/SSM only. S3: TESTINGOPS_STORAGE_PROVIDER=s3, bucket, region and an IAM user or instance role with s3:GetObject/PutObject/DeleteObject/ListBucket on that bucket. EKS: Helm chart with EBS CSI (gp3 StorageClass) and the AWS Load Balancer Controller as ingress.

Azure

Tier	Compute	Storage	Database	Evidence storage
Pilot	`Standard_D4s_v5` (4 vCPU / 16 GB) or `Standard_D4ps_v5` (arm64)	Premium SSD P10 128 GB	bundled	local disk
Standard	`Standard_D8s_v5` / `D8ps_v5` (8 vCPU / 32 GB)	Premium SSD P15 256 GB	Azure Database for PostgreSQL Flexible Server 16, `D2ds_v5`, zone-redundant HA; enable the `VECTOR` extension in server parameters	local disk or MinIO (Azure Blob is not S3-compatible)
Large	`Standard_D16s_v5` (16 vCPU / 64 GB)	Premium SSD P20 512 GB	Flexible Server `D4ds_v5`+, PITR	MinIO on Blob-backed disks, or Ceph

Notes: images come from Azure Container Registry (testingops.azurecr.io) with the pull token you receive. AKS: Helm chart with the managed-csi-premium StorageClass and the application routing (NGINX) add-on. Flexible Server requires azure.extensions to include VECTOR before the first migration runs.

GCP

Tier	Compute	Storage	Database	Evidence storage
Pilot	`e2-standard-4` (4 vCPU / 16 GB) or `t2a-standard-4` (arm64)	pd-balanced 100 GB	bundled	local disk
Standard	`n2-standard-8` / `t2a-standard-8` (8 vCPU / 32 GB)	pd-ssd 250 GB	Cloud SQL for PostgreSQL 16, 2 vCPU / 8 GB, HA; pgvector supported	Cloud Storage bucket via the S3 interoperability API (HMAC key)
Large	`n2-standard-16` (16 vCPU / 64 GB)	pd-ssd 500 GB	Cloud SQL 4 vCPU / 16 GB, PITR	Cloud Storage + lifecycle rule

Notes: Cloud Storage with TESTINGOPS_STORAGE_PROVIDER=s3, TESTINGOPS_STORAGE_S3_ENDPOINT=https://storage.googleapis.com, path-style addressing and an HMAC key for a service account. GKE: Helm chart with the premium-rwo StorageClass and the GKE Ingress or NGINX. Cloud SQL connections through the Cloud SQL Auth Proxy sidecar or a private IP.

Execution engine

Runs are executed by RunningOps, not by the TestingOps VM:

RunningOps cloud — nothing to install; the TestingOps VM needs outbound HTTPS to runningops.ai, and the applications under test must be reachable from the engine's fixed egress address.
RunningOps in your network — separate hosts: Linux x86_64 with KVM for Android virtual devices (8 vCPU / 32 GB per 8 devices), Apple Mac hosts for iOS simulators and real iPhones, USB-attached real Android devices on either. Browser workers: 2 vCPU / 4 GB per 4 parallel browsers. Sized with the TestingOps team based on the expected parallelism.

Checklist before installation

VM or cluster at the chosen tier, Docker 24+ or Kubernetes 1.27+.
DNS name for the UI and a certificate (or a public name for Let's Encrypt).
Outbound allow-list: registry, model provider, engine, trackers.
PostgreSQL with pgvector (bundled or managed) — CREATE EXTENSION vector succeeds.
Registry credentials, license file and the installation kit from the TestingOps team.
SMTP relay details (optional) and the first administrator's e-mail address.