Create the first cluster you can keep operating.

By the time you reach this step, the operator is installed and the target namespace is already onboarded when you are in the default multi-tenant mode. Start with the closest safe baseline, verify the cluster becomes healthy, and then move directly into the next operating concern.

Before you apply the cluster manifest

• confirm the operator install is healthy in the namespace model you chose
• confirm the target namespace is already onboarded through OpenBaoTenant when you are in multi-tenant mode
• choose a StorageClass explicitly for production before the first reconcile
• decide whether this cluster is only for evaluation or intended to become production

Choose the namespace handoff first

• In the default multi-tenant mode, create the target namespace and finish OpenBaoTenant onboarding before you apply OpenBaoCluster.
• In single-tenant mode, skip OpenBaoTenant and create the cluster only in the controller's watched namespace.

Decision matrix

Pick the first-cluster intent

Pick the first-cluster intent.

Intent	Start with	Do not skip	Go deeper
Local evaluation	Development profile with operator-managed TLS and minimal storage choices.	Treat it as disposable. Do not carry this profile into production.	Security profiles
Hardened production baseline	Hardened profile, self-init, External or ACME TLS, and explicit storage.	User access bootstrap, unseal configuration, and backups before the first risky upgrade.	Validated deployments
Dedicated team namespace	The hardened baseline plus the single-tenant operator install path.	Namespace ownership, rendered controller identity, and WATCH_NAMESPACE alignment.	Single-tenant mode

Start with the closest manifest

Local evaluation

Configure

Start a development-profile cluster for local evaluation

yaml

apiVersion: openbao.org/v1alpha1
kind: OpenBaoCluster
metadata:
name: dev-cluster
namespace: openbao-demo
spec:
version: "2.5.0"
replicas: 3
profile: Development
tls:
  enabled: true
  mode: OperatorManaged
  rotationPeriod: "720h"
storage:
  size: "10Gi"

Namespace choice still follows tenancy mode

If you are on the default multi-tenant path, openbao-demo must already be onboarded through OpenBaoTenant. If you are on the single-tenant path, replace openbao-demo with the namespace watched by the controller.

Evaluation only

The Development profile stores sensitive material in Kubernetes Secrets and relaxes production controls. Use it for local testing and CI, not for real environments.

Hardened baseline

Configure

Use a hardened baseline as the starting production shape

yaml

apiVersion: openbao.org/v1alpha1
kind: OpenBaoCluster
metadata:
name: prod-cluster
namespace: openbao-prod
spec:
version: "2.5.0"
replicas: 3
profile: Hardened
tls:
  enabled: true
  mode: External
storage:
  size: "50Gi"
  storageClassName: "fast-ssd"
selfInit:
  enabled: true
  oidc:
    enabled: true
  requests:
    # add at least one human login path before first exposure
    # for example: userpass, JWT, or Kubernetes auth
unseal:
  # configure cloud or transit auto-unseal before first reconcile

Do not apply the hardened example unchanged

Complete these before the first production reconcile:

1. finish the full selfInit contract so it includes both oidc.enabled: true for operator lifecycle auth and at least one human login path in selfInit.requests, using Self-Initialization and Operator Authentication
2. finish unseal with an external trust path such as cloud KMS, transit, KMIP, OCI KMS, or PKCS#11 in Unseal Configuration
3. finish the namespace handoff for your tenancy mode so openbao-prod is already onboarded in multi-tenant mode or is the watched namespace in single-tenant mode

Do not treat human auth as a post-bootstrap step

spec.selfInit.oidc.enabled: true gives the operator a JWT-based control path. It does not create a human login path. If the cluster will self-initialize, include at least one human auth method in selfInit.requests before the first reconcile so the cluster is usable after the root token is revoked.

Use a validated baseline when possible

If you are going straight to production, prefer a tested architecture or recipe under Validated Deployments rather than inventing the entire first manifest from scratch.

Apply and verify

Apply

Apply the cluster manifest

bash

kubectl apply -f cluster.yaml

Inspect

Inspect cluster phase and readiness

bash

kubectl get openbaocluster <name> -n <namespace> -o wide

Watch status.phase, readyReplicas, and whether the cluster reaches Available=True.

Verify

Watch the cluster pods stabilize

bash

kubectl get pods -l openbao.org/cluster=<name> -n <namespace> -w

A healthy first cluster should converge without repeated crash loops or long-lived pending state.

What to look for before you move on

Confirm the cluster is available, TLS and storage match the shape you intended, and hardened clusters can realistically progress toward ProductionReady=True.

Once the first cluster is healthy

Prepare for day 2Choose the next operating concern instead of leaving the cluster in a half-configured state.Expose the clusterPick the access path and TLS posture that match the security profile you chose.Configure backupsWire snapshots before the first risky change so restore is not first attempted during an incident.

Official OpenBao background

• OpenBao self-initialization