Deployment overview

What you stand up

Component	You provide	Salus provides
Cluster	OpenShift 4.x (tested on 4.22), Helm 3.8 or newer, the CloudNativePG operator	The salus-app Helm chart
Database	PostgreSQL 16 through CloudNativePG, or an external PostgreSQL 16	Schema, migrations, audit retention
Cache	Redis 7, deployed by the chart	Rate limiting, detection cache, FPE ledger
Images	A pull secret for ghcr.io/salusapp-ai, or a mirror	Seven service images, models baked in; OCR images optional
Keys	Five secrets you generate with openssl rand -hex 32	Nothing; keys never leave your cluster
TLS	An OpenShift route with edge termination, or your ingress and certificates

Sizing

Default resource requests in the chart add up to about 6.5 CPU and 9 GiB of memory with the default replica counts, of which the entity model service is the largest at 2 CPU and 2 GiB per replica. The database volume is 50 GiB by default. Throughput guidance is in the order of tens of requests per second per entity-model replica; measure on your own traffic during the pilot.

The architecture is AMD64 only. The ONNX models run on CPU. The optional OCR engine requests one GPU by default and has a CPU variant.

Topology

One public route to the console service, which serves the management console and proxies the API to the gateway. The gateway authenticates and signs every call to the main service. Detection services, PostgreSQL and Redis are cluster-internal. Nothing else is exposed, and the chart creates no route for the main service.

Isolated networks

Mirror the chart and the images into your registry, mirror the CloudNativePG and Redis images alongside them, then install with global.imageRegistry and global.imagePullSecrets pointing at the mirror. No step of the installation or of normal operation reaches the internet.

High availability

The default chart runs one PostgreSQL instance with backups off, two replicas of the entity model and the verifier, and one of everything else. For production, enable the chart’s scheduled backups to object storage, size the database storage class for your retention, and raise replicas on the detection services. Keep the main service at one replica while the LiteLLM guardrail is in use.

A rollout, in three steps

1. Install the chart, create the first administrator, a tenant and a key. OpenShift install.
2. Validate detection in the console playground on your own samples, then integrate one workflow.
3. Operate with the audit store, security events and metrics feeding your existing tooling. Audit and logging.