Deployment

Deployment options

Deployment into your own cloud account is delivered through the pilot programme, with CydraLabs engineers. The deployment package (Terraform, Helm chart and container images) is provided to pilot customers; contact us to join.

Components

Analytical services never sit on the action path: a decision needs the API, the database, the policy engine and (for rate limits) Redis. See the architecture.

Docker Compose (evaluation)

For evaluation and development, not production: it runs in development mode with development credentials, a development sign-in that needs no password, seeded fictional organisations and no TLS.

docker compose up --build
# optional OpenTelemetry collector:
docker compose --profile observability up --build
# reset all data:
docker compose down -v

The stack also runs PostgreSQL, Redis, OPA, SeaweedFS (S3-compatible storage), a one-off migration job and the worker. Sign in by choosing one of the seeded users of Northwind Financial Group or Contoso Health. On Windows, keep the checkout outside folders synchronised by OneDrive.

AWS reference deployment

Terraform for a production-shaped environment in your AWS account, in any region (examples use eu-west-1):

Deploying

1. Prerequisites: Terraform 1.9 or later, AWS CLI v2, kubectl, Helm 3, Docker with buildx, and an OIDC identity provider (Entra ID, Okta, Cognito or Keycloak) with the redirect URI https://<your host>/api/v1/auth/callback.
2. Copy the example variables file, set the environment, region, public URL, DNS zone and OIDC settings, then terraform init, plan and apply (about 25 to 35 minutes).
3. Store the OIDC client secret in the Secrets Manager entry Terraform created.
4. Run the deploy script. It builds arm64 images (with SBOM and provenance), installs the AWS Load Balancer Controller, creates the database roles, writes the Kubernetes secrets, installs the Helm chart with an atomic upgrade and runs smoke tests.

Kubernetes Helm chart

Chart cydralabs 0.1.0 (Kubernetes 1.27 or later). Databases, Redis and object storage are always external; the chart never contains secret values.

helm upgrade --install cydra ./cydralabs -n cydralabs --create-namespace \
  -f ./cydralabs/values-production.yaml

• Secrets: cydralabs-app (DATABASE_URL, REDIS_URL, SIGNING_KEY_SEED, SECRET_PEPPER, OIDC_CLIENT_SECRET, optional SIGNING_PREVIOUS_KEYS and S3 keys) and cydralabs-migrate (DATABASE_OWNER_URL). With IAM roles for service accounts, omit the S3 keys.
• Hardening: non-root (UID 10001), immutable root filesystem (readOnlyRootFilesystem), all capabilities dropped, no privilege escalation, RuntimeDefault seccomp, no service-account token mounted.
• Network policies: default deny, DNS allowed, per-component ingress, and egress limited to PostgreSQL, Redis, object storage and the identity provider.
• Images: pin by digest in production; a digest takes precedence over the tag.

Production settings

All settings are environment variables, validated at start-up. With ENVIRONMENT=production, the API, worker and migration job refuse to start when any of these is true:

• Development sign-in is enabled (AUTH_DEV_LOGIN_ENABLED).
• SIGNING_KEY_SEED or SECRET_PEPPER still has its development value.
• SESSION_COOKIE_SECURE is not true.
• CORS_ALLOWED_ORIGINS contains *.
• POLICY_FAIL_OPEN_READONLY is set without POLICY_FAIL_OPEN_ACKNOWLEDGED=true.
• OIDC_ISSUER, OIDC_CLIENT_ID or OIDC_CLIENT_SECRET is missing.
• EMAIL_BACKEND=smtp without SMTP_HOST, SMTP_USERNAME and SMTP_PASSWORD, or with SMTP_STARTTLS off; or the memory email backend, which is meant for tests.
• Self-service sign-up (AUTH_SIGNUP_ENABLED) without KEYCLOAK_SIGNUP_CLIENT_SECRET or without SMTP email.
• AUTH_EVENTS_SECRET is set but shorter than 32 characters.

Database and migrations

• Create two roles before running any migration: cydra_owner, which owns the schema, and cydra_app (LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOBYPASSRLS), which the application uses. The deploy script and the Compose stack do this for you.
• Migrations run as the owner (alembic upgrade head; the Helm hook or the Compose migrate job). The application must never connect as the owner: row-level security relies on the runtime role.
• Do not load demonstration data in production. Your organisation is created when its administrator signs in and completes onboarding.

Operating the platform

Health

GET /healthz reports that the process is up; GET /readyz also checks the database. The web app has its own /healthz.

Backups and restore

• PostgreSQL holds all authoritative state, including the evidence chain: use point-in-time recovery and test restores regularly.
• After a restore, verify the evidence chain (GET /api/v1/evidence/verify, or the verify-evidence command) and rebuild the graph (POST /api/v1/graph/rebuild).
• Redis needs no backup.

Upgrades

Migrations run before the new version starts. Schema changes are made in expand, migrate and contract steps so the previous version keeps working during a rolling upgrade. Roll back a release with helm rollback; check the release notes before rolling back across a migration.

Observability

Logs are structured JSON on standard output, with secrets and personal data redacted. Traces are exported over OTLP/HTTP (API requests and database calls; health checks excluded). Metrics and logs are not exported over OTLP in this release.

Applies to the CydraLabs proof-of-concept platform. Last updated 4 October 2026. Questions or corrections: contact us.