Examples on temporal-operator

Temporal UI on AKS via Application Gateway (AGIC)

Mon, 01 Jan 0001 00:00:00 +0000

Exposes the Temporal Web UI through the Azure Application Gateway Ingress Controller (AGIC).

Prerequisites #

An AKS cluster with the AGIC add-on enabled (az aks enable-addons --addons ingress-appgw ...) or AGIC installed via Helm.
A DNS record pointing temporal.example.com at the Application Gateway public IP.
A working persistence backend — combine this with cluster-azure-postgres-flexible.

Apply #

kubectl apply -f temporalcluster.yaml

The ingressClassName: azure-application-gateway selects AGIC; the appgw.ingress.kubernetes.io/* annotations tune the Application Gateway backend. Add TLS via an appgw.ingress.kubernetes.io/appgw-ssl-certificate annotation or the UI ingress tlsSecretName field once you have a certificate provisioned.

Azure Database for PostgreSQL Flexible Server (password auth)

Mon, 01 Jan 0001 00:00:00 +0000

A TemporalCluster backed by Azure Database for PostgreSQL Flexible Server using password authentication over TLS. This is the simplest Azure persistence option and works with the operator today.

Prerequisites #

A Flexible Server instance reachable from your AKS cluster (public access with firewall rules, or private access / VNet integration).
Two databases created on the server before applying this manifest — the operator runs setup-schema but does not create databases:

Passwordless Flexible Server via Azure Workload Identity

Mon, 01 Jan 0001 00:00:00 +0000

Demonstrates fully passwordless authentication to Azure Database for PostgreSQL Flexible Server using Azure Workload Identity and Microsoft Entra access tokens. No static passwords anywhere.

Actor	Token mechanism
Temporal server pods	`azure-token-refresher` sidecar writes `/azure/pgpass`; Temporal reads it via `passwordCommand` on every connection
Schema Job	one-shot `initContainer` writes `/azure/pgpass`; schema container reads it via `passwordCommand`
Operator (probe + schema inspection)	obtains an Entra token natively in-process via the Go Azure Workload Identity SDK — no sidecar, no shell required on the distroless image

This resolved #47.

cluster-cassandra

Mon, 01 Jan 0001 00:00:00 +0000

Manifests #

temporalcluster.yaml #

# Cassandra default + visibility store (single DC).
apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: cassandra
spec:
 version: "1.31.1"
 numHistoryShards: 512
 persistence:
 defaultStore:
 cassandra:
 hosts: ["cassandra-dc1-service"]
 port: 9042
 keyspace: temporal
 user: temporal
 datacenter: dc1
 passwordSecretRef: { name: cassandra-superuser, key: password }
 visibilityStore:
 cassandra:
 hosts: ["cassandra-dc1-service"]
 port: 9042
 keyspace: temporal_visibility
 user: temporal
 datacenter: dc1
 passwordSecretRef: { name: cassandra-superuser, key: password }

TemporalClusterClient — mTLS client credentials

Mon, 01 Jan 0001 00:00:00 +0000

A TemporalClusterClient issues mTLS client credentials for a Temporal cluster. The operator requests a cert-manager Certificate from the cluster’s mTLS CA issuer and writes the result (tls.crt, tls.key, ca.crt) into a Kubernetes Secret. Workers and client applications can then mount that Secret to connect to the cluster’s frontend over mTLS.

Requirement: this CRD only works against an mTLS-enabled TemporalCluster (mtls.provider: cert-manager). Against a non-mTLS TemporalCluster the controller reports a ClusterMTLSDisabled condition, and against a TemporalDevServer it reports DevServerUnsupported — in both cases it issues no certificate.

cluster-cnpg-integrated

Mon, 01 Jan 0001 00:00:00 +0000

Manifests #

01-cnpg.yaml #

# CloudNativePG (CNPG) Postgres used as the Temporal datastore.
#
# Prerequisite: the CNPG operator must be installed in the cluster, e.g.:
# kubectl apply --server-side -f \
# https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.24/releases/cnpg-1.24.0.yaml
#
# Two things Temporal needs that aren't obvious:
#
# 1. Two databases. The operator only runs schema setup (setup-schema); it
# does NOT create databases. initdb creates "temporal"; the postInitSQL
# below creates the separate "temporal_visibility" database.
#
# 2. Enough connections. Each Temporal service pod opens a connection pool to
# BOTH stores, which blows past Postgres's default max_connections of 100
# and surfaces as "remaining connection slots are reserved for ... SUPERUSER"
# (SQLSTATE 53300). Raise it to 200.
#
# CNPG generates a Secret "temporal-pg-app" (keys: username, password) for the
# "temporal" app user, referenced by the TemporalCluster. Do NOT redeclare the
# "temporal" role under spec.managed.roles without a passwordSecret — CNPG would
# reset it to PASSWORD NULL / NOLOGIN and break password authentication.
apiVersion: v1
kind: Namespace
metadata:
 name: temporal
---
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
 name: temporal-pg
 namespace: temporal
spec:
 instances: 1
 storage:
 size: 5Gi
 postgresql:
 parameters:
 max_connections: "200"
 bootstrap:
 initdb:
 database: temporal
 owner: temporal
 postInitSQL:
 - CREATE DATABASE temporal_visibility OWNER temporal;

02-temporalcluster.yaml #

# A TemporalCluster backed by the CNPG Postgres from 01-cnpg.yaml.
#
# The operator reconciler pings the datastore from its OWN pod (in the
# temporal-system namespace), so the persistence host must be a
# namespace-qualified FQDN. A bare "temporal-pg-rw" would resolve in the
# operator's namespace and fail with PersistenceUnreachable.
apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: temporal
 namespace: temporal
spec:
 version: "1.31.1"
 numHistoryShards: 512
 persistence:
 defaultStore:
 sql:
 pluginName: postgres12
 host: temporal-pg-rw.temporal.svc.cluster.local
 port: 5432
 database: temporal
 user: temporal
 passwordSecretRef:
 name: temporal-pg-app
 key: password
 visibilityStore:
 sql:
 pluginName: postgres12
 host: temporal-pg-rw.temporal.svc.cluster.local
 port: 5432
 database: temporal_visibility
 user: temporal
 passwordSecretRef:
 name: temporal-pg-app
 key: password
 # Web UI. Reach it with `kubectl -n temporal port-forward svc/temporal-ui
 # 8080:8080`, or uncomment the ingress block to expose it.
 ui:
 enabled: true
 # ingress:
 # enabled: true
 # ingressClassName: nginx
 # host: temporal.example.com
 # tlsSecretName: temporal-example-com-tls
 # annotations:
 # cert-manager.io/cluster-issuer: letsencrypt-prod
---
# Declarative namespace registered on the cluster once it is Ready.
apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalNamespace
metadata:
 name: default
 namespace: temporal
spec:
 clusterRef:
 name: temporal
 retentionPeriod: "72h"
 description: "Default namespace"
 allowDeletion: true

cluster-elasticsearch-visibility

Mon, 01 Jan 0001 00:00:00 +0000

Manifests #

temporalcluster.yaml #

# Postgres default store with Elasticsearch advanced visibility.
apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: es-visibility
spec:
 version: "1.31.1"
 numHistoryShards: 512
 persistence:
 defaultStore:
 sql:
 pluginName: postgres12
 host: postgres.default.svc
 port: 5432
 database: temporal
 user: temporal
 passwordSecretRef: { name: temporal-store, key: password }
 visibilityStore:
 elasticsearch:
 url: https://elasticsearch-es-http:9200
 version: v8
 username: elastic
 passwordSecretRef: { name: elasticsearch-es-elastic-user, key: elastic }
 tls: { enabled: true }

Microsoft Entra Authentication

Mon, 01 Jan 0001 00:00:00 +0000

Demonstrates a TemporalCluster configured for Microsoft Entra (Azure AD) authentication on two layers:

Layer	Mechanism
Service-to-service	Entra-issued JWTs validated server-side; `roles` claim enforces per-namespace access via Temporal’s authorizer
Temporal UI	Human login via Entra OIDC; client secret synced from 1Password

Prerequisites #

An Entra app registration for the Temporal server with:
- App Roles defined (e.g. temporal-namespace-admin, temporal-namespace-writer, temporal-namespace-reader).
- The tenant ID noted as <TENANT_ID>.
A second Entra app registration (or the same one) for the Temporal UI OIDC flow with:
- A client secret created and stored in 1Password under vault Kubernetes, item temporal-ui-oidc, field name client-secret.
- A redirect URI pointing to https://temporal.example.com/auth/sso/callback.
- The client ID noted as <CLIENT_ID>.
The 1Password Kubernetes Operator installed in the cluster so that OnePasswordItem resources sync secrets automatically.
A running PostgreSQL instance accessible as temporal-pg-rw:5432, with a temporal-pg-app secret containing a password key.

Customize #

Replace the placeholder values before applying:

cluster-mtls-cert-manager

Mon, 01 Jan 0001 00:00:00 +0000

Manifests #

issuer.yaml #

# A self-signed root issuer and CA, then a CA issuer that the operator uses to
# mint internode and frontend certificates. Requires cert-manager installed.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
 name: temporal-selfsigned
spec:
 selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: temporal-ca
spec:
 isCA: true
 commonName: temporal-ca
 secretName: temporal-ca
 privateKey:
 algorithm: ECDSA
 size: 256
 issuerRef:
 name: temporal-selfsigned
 kind: Issuer
 group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
 name: temporal-ca-issuer
spec:
 ca:
 secretName: temporal-ca

temporalcluster.yaml #

# A TemporalCluster with cert-manager-driven mTLS, backed by the CNPG Postgres
# from the postgres suite fixtures.
apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: temporal-mtls
spec:
 version: "1.31.1"
 numHistoryShards: 512
 mtls:
 provider: cert-manager
 issuerRef:
 name: temporal-ca-issuer
 kind: Issuer
 persistence:
 defaultStore:
 sql:
 pluginName: postgres12
 host: temporal-pg-rw
 port: 5432
 database: temporal
 user: temporal
 passwordSecretRef:
 name: temporal-pg-app
 key: password
 visibilityStore:
 sql:
 pluginName: postgres12
 host: temporal-pg-rw
 port: 5432
 database: temporal_visibility
 user: temporal
 passwordSecretRef:
 name: temporal-pg-app
 key: password

cluster-postgres-full

Mon, 01 Jan 0001 00:00:00 +0000

Manifests #

temporalcluster.yaml #

# Production-leaning Postgres cluster with per-service sizing, UI, and metrics.
apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: full
spec:
 version: "1.31.1"
 numHistoryShards: 4096
 services:
 frontend: { replicas: 2, resources: { requests: { cpu: 250m, memory: 256Mi } } }
 history: { replicas: 5, resources: { requests: { cpu: 500m, memory: 512Mi } } }
 matching: { replicas: 3 }
 worker: { replicas: 2 }
 ui:
 enabled: true
 ingress:
 enabled: true
 ingressClassName: nginx
 host: temporal.example.com
 metrics:
 enabled: true
 serviceMonitor:
 enabled: true
 labels: { release: kube-prometheus-stack }
 persistence:
 defaultStore:
 sql:
 pluginName: postgres12
 host: postgres-rw.default.svc
 port: 5432
 database: temporal
 user: temporal
 passwordSecretRef: { name: temporal-store, key: password }
 tls: { enabled: true }
 visibilityStore:
 sql:
 pluginName: postgres12
 host: postgres-rw.default.svc
 port: 5432
 database: temporal_visibility
 user: temporal
 passwordSecretRef: { name: temporal-store, key: password }
 tls: { enabled: true }

cluster-postgres-minimal

Mon, 01 Jan 0001 00:00:00 +0000

Manifests #

temporalcluster.yaml #

# Minimal single-version Temporal cluster backed by Postgres.
apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: minimal
spec:
 version: "1.31.1"
 numHistoryShards: 512
 persistence:
 defaultStore:
 sql:
 pluginName: postgres12
 host: postgres.default.svc
 port: 5432
 database: temporal
 user: temporal
 passwordSecretRef: { name: temporal-store, key: password }
 visibilityStore:
 sql:
 pluginName: postgres12
 host: postgres.default.svc
 port: 5432
 database: temporal_visibility
 user: temporal
 passwordSecretRef: { name: temporal-store, key: password }

cluster-upgrade

Mon, 01 Jan 0001 00:00:00 +0000

Manifests #

01-temporalcluster-1.30.yaml #

apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: temporal-upgrade
spec:
 version: "1.30.4"
 numHistoryShards: 512
 persistence:
 defaultStore:
 sql:
 pluginName: postgres12
 host: temporal-pg-rw
 port: 5432
 database: temporal
 user: temporal
 passwordSecretRef:
 name: temporal-pg-app
 key: password
 visibilityStore:
 sql:
 pluginName: postgres12
 host: temporal-pg-rw
 port: 5432
 database: temporal_visibility
 user: temporal
 passwordSecretRef:
 name: temporal-pg-app
 key: password

02-temporalcluster-1.31.yaml #

apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: temporal-upgrade
spec:
 version: "1.31.1"
 numHistoryShards: 512
 persistence:
 defaultStore:
 sql:
 pluginName: postgres12
 host: temporal-pg-rw
 port: 5432
 database: temporal
 user: temporal
 passwordSecretRef:
 name: temporal-pg-app
 key: password
 visibilityStore:
 sql:
 pluginName: postgres12
 host: temporal-pg-rw
 port: 5432
 database: temporal_visibility
 user: temporal
 passwordSecretRef:
 name: temporal-pg-app
 key: password

cluster-with-namespaces-and-search-attributes

Mon, 01 Jan 0001 00:00:00 +0000

Manifests #

resources.yaml #

# A cluster plus a declarative namespace and custom search attribute.
apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: app
spec:
 version: "1.31.1"
 numHistoryShards: 512
 persistence:
 defaultStore:
 sql: { pluginName: postgres12, host: postgres.default.svc, port: 5432, database: temporal, user: temporal, passwordSecretRef: { name: temporal-store, key: password } }
 visibilityStore:
 sql: { pluginName: postgres12, host: postgres.default.svc, port: 5432, database: temporal_visibility, user: temporal, passwordSecretRef: { name: temporal-store, key: password } }
---
apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalNamespace
metadata:
 name: orders
spec:
 clusterRef: { name: app }
 retentionPeriod: "168h"
 description: "Orders processing"
---
apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalSearchAttribute
metadata:
 name: customer-id
spec:
 clusterRef: { name: app }
 namespace: orders
 name: CustomerId
 type: Keyword

TemporalDevServer examples

Mon, 01 Jan 0001 00:00:00 +0000

TemporalDevServer runs a single-pod temporal server start-dev instance backed by embedded SQLite. It is designed for local development and CI — not for production. Data is ephemeral by default (wiped on pod restart); a Persistent variant keeps data across restarts via a PVC.

File	Description
`minimal.yaml`	Minimal ephemeral dev server (`dev`) — SQLite, UI enabled, no extra setup.
`persistent.yaml`	Dev server with a PVC (`dev-persistent`) and two extra namespaces (`orders`, `billing`).
`namespace-on-devserver.yaml`	`TemporalNamespace` targeting the `dev` server via the polymorphic `clusterRef`.

Apply #

# Minimal (ephemeral) dev server:
kubectl apply -f minimal.yaml

# Persistent variant with pre-created namespaces:
kubectl apply -f persistent.yaml

# Managed namespace pointing at the dev server:
kubectl apply -f namespace-on-devserver.yaml

# Check status (short name: tds):
kubectl get temporaldevservers
kubectl get tds

Accessing the dev server #

The operator creates a Service named <name>-devserver in the same namespace:

multi-cluster

Mon, 01 Jan 0001 00:00:00 +0000

Manifests #

cluster-a.yaml #

apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: cluster-a
spec:
 version: 1.31.1
 numHistoryShards: 512
 clusterMetadata:
 enableGlobalNamespace: true
 failoverVersionIncrement: 100
 currentClusterName: "clusterA"
 initialFailoverVersion: 1
 masterClusterName: "clusterA"
 mtls:
 provider: cert-manager
 issuerRef:
 name: shared-ca-issuer
 kind: ClusterIssuer
 frontend:
 dnsNames:
 - "cluster-a.example.com"
 persistence:
 defaultStore:
 sql:
 pluginName: postgres12
 host: postgres.default.svc
 port: 5432
 database: temporal
 user: temporal
 passwordSecretRef:
 name: temporal-pg
 key: password
 visibilityStore:
 sql:
 pluginName: postgres12
 host: postgres.default.svc
 port: 5432
 database: temporal_visibility
 user: temporal
 passwordSecretRef:
 name: temporal-pg
 key: password

cluster-b.yaml #

apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalCluster
metadata:
 name: cluster-b
spec:
 version: 1.31.1
 numHistoryShards: 512
 clusterMetadata:
 enableGlobalNamespace: true
 failoverVersionIncrement: 100
 currentClusterName: "clusterB"
 initialFailoverVersion: 2
 masterClusterName: "clusterA"
 mtls:
 provider: cert-manager
 issuerRef:
 name: shared-ca-issuer
 kind: ClusterIssuer
 frontend:
 dnsNames:
 - "cluster-b.example.com"
 persistence:
 defaultStore:
 sql:
 pluginName: postgres12
 host: postgres.default.svc
 port: 5432
 database: temporal
 user: temporal
 passwordSecretRef:
 name: temporal-pg
 key: password
 visibilityStore:
 sql:
 pluginName: postgres12
 host: postgres.default.svc
 port: 5432
 database: temporal_visibility
 user: temporal
 passwordSecretRef:
 name: temporal-pg
 key: password

cluster-connection.yaml #

apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalClusterConnection
metadata:
 name: dr-pair
spec:
 peers:
 - name: clusterA
 clusterRef:
 name: cluster-a
 - name: clusterB
 clusterRef:
 name: cluster-b

global-namespace.yaml #

apiVersion: temporal.bmor10.com/v1alpha1
kind: TemporalNamespace
metadata:
 name: my-global-ns
spec:
 clusterRef:
 name: cluster-a
 isGlobal: true
 clusters: [clusterA, clusterB]
 activeCluster: clusterA
 retentionPeriod: 72h

Declarative Temporal schedules

Mon, 01 Jan 0001 00:00:00 +0000

Four TemporalSchedule resources that exercise the different trigger styles and options the CRD supports. Each schedule is its own file; they share a cluster and namespace defined in 00-shared.yaml.

File	Trigger	Highlights
`00-shared.yaml`	—	Shared `TemporalCluster` (`app`) + `TemporalNamespace` (`scheduling`). Apply first.
`nightly-report.yaml`	Cron (`0 2 * * *`, NY time)	`args`, `retryPolicy`, `memo`, `overlapPolicy: Skip`, `pauseOnFailure`
`healthcheck-every-15m.yaml`	Interval (`every: 15m`, `offset: 2m`)	`jitter`
`business-hours-sync.yaml`	Structured calendar	weekdays 09:00–17:00 hourly, no cron syntax
`maintenance-window.yaml`	Cron (Sundays 03:00)	starts `paused: true`

All four schedules set allowDeletion: true, so deleting the CR also deletes the schedule in Temporal. Set it to false (the default) to leave the schedule in place when the CR is removed.

Operator UI example

Mon, 01 Jan 0001 00:00:00 +0000

The operator serves a read-only UI when you set --ui-bind-address (e.g. :8082). It is disabled by default. The UI performs no authentication itself; front it with a forward-auth proxy such as Authelia and pass the trusted identity headers through.

Enable the UI on the manager by adding --ui-bind-address=:8082 to its arguments. With the Helm chart that means appending it to manager.args in your values (alongside --leader-elect); with raw kustomize, add it to the manager container args.
Apply config/ui to expose the operator-ui Service.
Apply ingress-authelia.yaml (edit hosts/URLs) so Authelia authenticates users and injects Remote-User / Remote-Groups / Remote-Email.
Set --ui-require-auth whenever the Service is exposed so the operator returns 401 for requests without the trusted user header (fail closed).

Security #

Forward-auth on the Ingress only protects requests that arrive through that Ingress. The operator-ui Service still routes directly to the manager pod on port 8082, so direct in-cluster access (including kubectl port-forward svc/operator-ui 8082) bypasses Authelia unless the manager also enforces --ui-require-auth.