Install — Kubernetes / OpenShift (Helm)

Run the platform as cluster-managed workloads in any Kubernetes or OpenShift cluster — in any cloud or on-prem — for high availability and horizontal scale.

Since v1.0 the Helm chart is generally available and ships in the release artefact bundle.

---

When to choose Helm

• You already run Kubernetes or OpenShift and want the platform managed the same way as the rest of your workloads.
• You want high availability — multiple runtime replicas, rolling updates, pod self-healing.
• You want to point at a managed or in-cluster PostgreSQL that you operate independently of the application pods.

---

Prerequisites

• A Kubernetes 1.28+ (or equivalent OpenShift) cluster with an Ingress controller and cert-manager (or your own TLS provisioning)
• PostgreSQL 15+ reachable from cluster pods — an in-cluster operator or a managed service both work
• A dedicated namespace (e.g. s2r)
• An OIDC identity provider configured for cluster ingress (the standard identity path for non-GCP topologies)
• The two install secrets created as Kubernetes Secrets: the database password and the credential key (see Configuration reference)

---

Shape of the deployment

The chart deploys one Deployment per service — admin-api, admin-ui, runtime, and worker — plus a Service and Ingress for the UI/API. admin-api owns the Flyway migrations and applies them on startup, so it must reach a healthy state before runtime and worker depend on the new schema; standard rolling-update ordering handles this (deploy admin-api first when you upgrade — see the upgrade guide).

PostgreSQL is external to the chart's application workloads: you supply connection details and a Secret reference. This keeps the database lifecycle (backups, failover, version upgrades) under your control. See Backup & restore.

Chart specifics — version, values keys, and resource defaults — are documented with the release artefact you receive. The values below illustrate the shape; treat the bundled chart's values.yaml and its README as authoritative for exact key names and defaults.

---

Install

The chart is delivered under deploy/helm/s2r/ in the release artefact bundle. Install it directly or add it to your local Helm repo:

helm install s2r ./deploy/helm/s2r \
    --namespace s2r --create-namespace \
    --values my-values.yaml

Example my-values.yaml

global:
  domain: s2r.<your-domain>
  adminBootstrapEmails:
    - first.admin@<your-org>

postgres:
  host: postgres.<your-db-host>
  port: 5432
  database: soap_to_rest
  user: s2r_app
  passwordSecretRef: s2r-db-password      # k8s Secret name (the DB password)

# AES key for encrypting backend-profile credentials in the DB.
credentialKey:
  secretRef: s2r-credential-key           # k8s Secret name

oidc:
  issuerUrl: https://idp.<your-domain>/...
  clientId: s2r-admin-ui
  clientSecretRef: s2r-oidc-client-secret

resources:
  adminApi: { cpu: 1,   memory: 2Gi }
  adminUi:  { cpu: 0.5, memory: 512Mi }
  runtime:  { cpu: 2,   memory: 2Gi }
  worker:   { cpu: 1,   memory: 1Gi }

ingress:
  className: nginx
  tlsSecretName: s2r-tls
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt

Apply and verify

helm upgrade --install s2r ./deploy/helm/s2r \
    --namespace s2r --create-namespace \
    --values my-values.yaml

kubectl -n s2r rollout status deployment/admin-api
kubectl -n s2r rollout status deployment/admin-ui
kubectl -n s2r rollout status deployment/runtime
kubectl -n s2r rollout status deployment/worker

Browse to https://s2r.<your-domain>/ and log in via your OIDC provider. The first authenticated user becomes the bootstrap admin (see first boot).

---

High availability notes

• Runtime scales horizontally. Increase the runtime replica count for throughput; the runtime is stateless and reads route configuration from PostgreSQL with a short-lived cache. Keep a minimum of 1 replica to avoid cold-start latency.
• admin-api and worker can run with a single replica for most installs; the worker's aggregation jobs are idempotent. Scale admin-api for heavier operator/UI concurrency.
• PostgreSQL is the single source of truth for config and state — make it highly available (managed HA service or an operator with replication). The application pods are disposable.
• Rolling upgrades: deploy admin-api first so the schema is migrated before runtime/worker pods cycle. Roll back with helm rollback s2r <revision> -n s2r.

---

OpenShift

The same chart applies on OpenShift. Use OpenShift Routes (or your ingress controller) for the edge, and ensure the service accounts have a security context compatible with your cluster's SCC policy. Identity integration is via OIDC as on any Kubernetes cluster.

---

Next steps

• Configuration reference
• Deployment runbook — service ordering and provenance.
• Operations overview

---

All Specaria SOAP to REST docs