Prepare the installation environment

Complete these steps before you install the automation orchestrator operator. You must provision PostgreSQL and create database Secrets regardless of the installation method you choose.

Procedure

Create a dedicated namespace to isolate the automation orchestrator resources from other workloads on the cluster.
```
$ oc create namespace automation-orchestrator
```
Provision a PostgreSQL instance accessible from the target cluster with three databases.
- One database for the automation orchestrator backend (for example, orchestrator).
- One database for the Temporal workflow engine (for example, temporal).
- A database named temporal_visibility for the Temporal visibility store. This name is fixed and cannot be changed.
You can choose any name for the backend and Temporal databases. The names you choose must match the values you set in the corresponding Kubernetes Secrets.
Create a dedicated database user for each database.
Each user must own its respective databases because the operator runs schema migrations that require DDL privileges (CREATE, ALTER, DROP). SUPERUSER is not required. The Temporal user must have access to both the Temporal database and temporal_visibility.

The backend database requires the pgcrypto extension. If the database user cannot create extensions, have your database administrator pre-install pgcrypto.

The following SQL shows the recommended production setup:
```
CREATE USER orchestrator WITH PASSWORD 'secure-password';
CREATE USER temporal WITH PASSWORD 'secure-password';

CREATE DATABASE orchestrator OWNER orchestrator;
CREATE DATABASE temporal OWNER temporal;
CREATE DATABASE temporal_visibility OWNER temporal;

GRANT ALL PRIVILEGES ON DATABASE orchestrator TO orchestrator;
GRANT ALL PRIVILEGES ON DATABASE temporal TO temporal;
GRANT ALL PRIVILEGES ON DATABASE temporal_visibility TO temporal;

-- Connect to the orchestrator database and install the required extension.
\c orchestrator
CREATE EXTENSION IF NOT EXISTS pgcrypto;
```
Note:

See Automation orchestrator system requirements for the supported PostgreSQL version.
Record the connection details (host, port, database names, credentials) for use in the Kubernetes Secrets.
Create the required database Secrets and any optional Secrets in the target namespace before you deploy the automation orchestrator operator.
For the YAML format of every required and optional Secret, see Kubernetes Secrets for automation orchestrator.

At minimum, you must create:
- orchestrator-pg-credentials with the backend database connection details.
- temporal-pg-credentials with the Temporal database connection details.
Optional: If your security policy requires certificates from a specific certificate authority (CA), prepare custom TLS certificates before installation.

The operator generates a self-signed CA and per-service certificates by default. Skip this step to use the auto-generated certificates.

For the full procedure, see Provide your own internal TLS certificates.

Kubernetes Secrets for automation orchestrator

Use this reference to look up the format of each Kubernetes Secret that the automation orchestrator operator reads. Create these Secrets in the target namespace before you deploy the AutomationOrchestrator custom resource.

Overview

The automation orchestrator operator auto-generates optional secrets when you do not provide them. These include JWT signing keys, the credential encryption key, the Redis password, and the initial admin password. If your security policy requires you to provide your own, create the Secrets listed below. Reference them in the spec.secrets section of the AutomationOrchestrator custom resource.

The automation orchestrator operator watches all Secrets and ConfigMaps referenced by the custom resource. When you update a referenced Secret or ConfigMap, the operator detects the change. It triggers a rolling restart of affected pods.

Required: PostgreSQL credentials for the backend database

apiVersion: v1
kind: Secret
metadata:
  name: orchestrator-pg-credentials
  namespace: automation-orchestrator
type: Opaque
stringData:
  database: "orchestrator"
  username: "orchestrator_user"
  password: "your-secure-password"

Required: PostgreSQL credentials for the Temporal database

apiVersion: v1
kind: Secret
metadata:
  name: temporal-pg-credentials
  namespace: automation-orchestrator
type: Opaque
stringData:
  database: "temporal"
  username: "temporal_user"
  password: "your-secure-password"

Optional: PostgreSQL CA certificate

Required when sslMode is verify-ca or verify-full:

apiVersion: v1
kind: Secret
metadata:
  name: orchestrator-pg-ca
  namespace: automation-orchestrator
type: Opaque
data:
  ca.crt: base64-encoded-CA-certificate

Optional: PostgreSQL client certificate for mutual TLS

Required when the PostgreSQL server enforces mutual TLS (mTLS) client certificate authentication. Only valid when sslMode is require, verify-ca, or verify-full.

apiVersion: v1
kind: Secret
metadata:
  name: orchestrator-pg-client-cert
  namespace: automation-orchestrator
type: kubernetes.io/tls
data:
  tls.crt: base64-encoded-client-certificate
  tls.key: base64-encoded-client-private-key

The automation orchestrator operator mounts this certificate into the backend, worker, and Temporal components.

Optional: S3 access credentials

If your S3-compatible endpoint requires authentication, create a Secret with the access credentials. Reference this Secret in spec.fileStorage.credentialSecretRef on the AutomationOrchestrator custom resource.

apiVersion: v1
kind: Secret
metadata:
  name: s3-credentials
  namespace: automation-orchestrator
type: Opaque
stringData:
  access-key-id: "your-access-key-id"
  secret-access-key: "your-secret-access-key"

Optional: S3 endpoint CA certificate

Required when the S3 endpoint uses a private CA:

apiVersion: v1
kind: Secret
metadata:
  name: s3-ca-cert
  namespace: automation-orchestrator
type: Opaque
data:
  ca.crt: base64-encoded-CA-certificate

Optional: JWT primary signing key

ES256 (ECDSA P-256). For details on the signing algorithm and key rotation, see Authentication security.

apiVersion: v1
kind: Secret
metadata:
  name: my-jwt-primary
  namespace: automation-orchestrator
type: Opaque
data:
  jwt-primary.pem: base64-encoded-PKCS8-EC-private-key

Optional: JWT backup signing key

Same format as the primary key, for key rotation:

apiVersion: v1
kind: Secret
metadata:
  name: my-jwt-backup
  namespace: automation-orchestrator
type: Opaque
data:
  jwt-backup.pem: base64-encoded-PKCS8-EC-private-key

Optional: Credential encryption key

64-character hex string (32 bytes) for AES-256-GCM:

apiVersion: v1
kind: Secret
metadata:
  name: my-encryption-key
  namespace: automation-orchestrator
type: Opaque
stringData:
  secret-encryption-key: "64-character-hex-string"

To generate a valid encryption key:

$ openssl rand -hex 32

Optional: Redis password

apiVersion: v1
kind: Secret
metadata:
  name: my-redis-password
  namespace: automation-orchestrator
type: Opaque
stringData:
  password: "your-secure-redis-password"

Optional: Initial admin password

Set the password for the admin user that the operator creates during the first deployment. When you omit this Secret, the automation orchestrator operator generates a random password. You can retrieve the auto-generated password after deployment completes. See Retrieve the initial admin password.

apiVersion: v1
kind: Secret
metadata:
  name: my-admin-password
  namespace: automation-orchestrator
type: Opaque
stringData:
  password: "your-secure-admin-password"

The operator uses the initial admin password only during the first deployment. After the admin user exists, changing or deleting this Secret has no effect.