Before you start

Make these decisions before you run anything. Most can change later; the ones listed under What cannot be changed later cannot without a migration.

The decisions

1. The install path

The operator on OpenShift 4.20 or later; the Helm chart on Oracle OKE and other Kubernetes. Installation overview explains why.

2. Where the database lives

The database holds every tenant, key, usage record, billing statement and audit entry.

	Bundled	Managed	Your own
What it is	One PostgreSQL instance on one volume	Three PostgreSQL instances run by the PostgreSQL operator, with failover	A PostgreSQL 14 or later server you operate
Prepare in advance	Nothing	The PostgreSQL operator, an S3-compatible bucket for backups	The database, a role that owns it, a connection string
Backup and point-in-time recovery	None	Continuous archiving to your bucket	Whatever you already run
Right for	Evaluation, demonstrations, pilots	Production	Production, where a DBA team owns PostgreSQL

For your own database, create the database and a role that owns it. Olympusx AI applies its own schema at start-up, so the role needs DDL rights on that database and nothing beyond it:

CREATE ROLE olympus LOGIN PASSWORD '<password>';
CREATE DATABASE olympus OWNER olympus;

The application must not connect as a superuser or as a role with BYPASSRLS: the tenant row-level security policies bind every other role, the owner included.

3. Which identity provider signs people in

The built-in identity service. Olympusx AI deploys it, creates the first platform administrator, and lets tenant administrators invite people from the console. It serves sign-in on the console’s hostname under /auth.
Your own OIDC provider. Olympusx AI trusts its issuer and audience. People and roles are managed in your provider. Tokens must carry the claims described in Identity and sign-in.

The platform refuses to start with authentication off.

4. Two hostnames

The console and the gateway are separate hosts, so the gateway can have its own certificate, rate limits and firewall posture, and the console can stay on the internal network while the API is published.

On OpenShift, put both directly under the cluster’s apps domain (olympus.apps.example.com and olympus-api.apps.example.com). The router’s default certificate covers one label deep, so api.olympus.apps.example.com is not covered.

5. The master key

The master key seals every credential Olympusx AI stores: registered cluster tokens, model provider keys, tool server and connector credentials. Generate one per environment, store it, and keep it for the life of the installation:

openssl rand -base64 32

Escrow it wherever you keep other master keys before you store anything with it.

6. Registry access

Your subscription comes with a registry address and a pull credential. Either the cluster pulls from that registry with a pull secret, or you mirror every image into your own registry first (Air-gapped installation).

7. Mail

Name the SMTP relay the built-in identity service sends invitations through: host, port (587 with STARTTLS, or 465 with implicit TLS), sender address, and a login if the relay needs one.

8. Guardrails

The guardrails service is off in the chart’s defaults. Without it, prompts and completions pass through uninspected, and a tenant’s guardrail policy has nothing enforcing it. Turn it on before production traffic, or point Olympusx AI at a scanner you already run (Guardrails).

9. Backups

For the managed database: an S3-compatible bucket, its endpoint, and an access key pair. Without a backup destination there is no point-in-time recovery, and with the operator, deleting the Olympus resource deletes the database. Backup and restore has the procedure and the restore drill.

10. Database privilege separation

With tenant isolation on, the control plane connects as a restricted role that can read and write rows but cannot change tables or drop the row-level security policies. A DBA creates that role once (Configuration). Decide now whether your install needs it; a regulated multi-tenant install does.

The values to collect

Placeholder in these pages	What it is
`<registry>`	The registry path from your subscription, or your mirror of it
`<registry-host>`	The host part of `<registry>`
`<registry-username>`, `<registry-token>`	The pull credential from your subscription
`<pull-secret>`	The name you give the image pull Secret, for example `olympus-pull`
`<version>`	The Olympusx AI release you install, for example `1.1.0`
`<console-host>`	Where people open the console
`<gateway-host>`	The OpenAI-compatible API applications call
`<admin-email>`	The first platform administrator’s email address, which is also their username
`<storage-class>`	A ReadWriteOnce StorageClass for the database

These pages install into the namespace olympus, as the Helm release olympus or the Olympus resource olympus. Every object name derives from those names, and every command here assumes them.

What cannot be changed later

The master key. Credentials sealed with it cannot be opened without it.
The database. Moving it later, including off the bundled one, is a data migration, not a values change.
The console hostname, with the built-in identity service. The sign-in realm is created with it at first start, and every token’s issuer is built from it. A new hostname afterwards means editing the realm by hand.
The realm and its path. The realm name (olympus by default) and the path sign-in is served under (/auth by default) are part of the issuer.
The first administrator, the mail relay and the password policy, as set at install. The built-in identity service imports its realm once. Changing these values on a running platform changes nothing; you change them in the identity service’s administration console instead (Identity and sign-in).
The names. The namespace, and the release or resource name. Cluster-scoped objects take their names from the release or resource name, so two installs on one cluster need different names.