Bootstrap one node, initialize safely, then scale to the requested cluster shape.

Day 1 begins when OpenBaoCluster is created. The control plane bootstraps TLS and unseal prerequisites, renders the workload, keeps the StatefulSet at one replica for safe initialization, then hands off into steady-state operations only after the cluster is known-good.

At a glance

Starts with

• OpenBaoCluster creation and the requested replica count
• TLS mode, unseal mode, and optional self-init configuration
• a provisioned namespace boundary from Day 0 when multi-tenancy is in use

Primary owners

• internal/service/certs
• internal/service/infra
• internal/service/init

Writes

• TLS Secrets, trust-bundle surfaces, and rendered config.hcl
• single-replica StatefulSet followed by scale-out after initialization
• status.initialized, status.selfInitialized, and initial autopilot configuration

Hands off to

• steady-state workload reconciliation once the cluster is initialized
• day 2 upgrade, maintenance, and backup workflows
• operator-facing configuration and first-cluster guides

Architectural Placement

Day 1 creation crosses three workload-side services in sequence:

1. The cert manager ensures TLS material exists or is ready to be observed.
2. The infrastructure manager renders the workload contract and keeps the StatefulSet at one replica.
3. The init manager initializes the cluster, configures autopilot defaults, and only then permits scale-out.

That split keeps first-boot safety logic separate from routine steady-state reconciliation.

Diagram

Day 1 creation flow

First boot is a controlled handoff: TLS and rendered config first, one-node bootstrap second, initialization and autopilot third, then scale-out into the requested cluster size.

Decision matrix

Initialization paths

Initialization paths.

Path	Best fit	What changes in the control plane
Self-init	Recommended when OpenBao supports native self-initialization and you want no root-token Secret in the cluster.	The workload renders self-init requests for pod-0, initialization is detected rather than performed by the operator, and status.selfInitialized becomes true.
Standard initialization	Use when self-init is not enabled or you need the operator to drive /sys/init directly.	The init manager performs the init call, stores the root token in a Secret, then marks status.initialized before scale-out.

Self-init

Self-init flow

• Cert and infra managers prepare TLS, seal, and rendered config as usual, but pod-0 receives self-init requests in the rendered startup configuration.
• OpenBao initializes itself on first start and auto-revokes the transient root token instead of returning it to the operator.
• The init manager detects successful initialization through service-registration labels or equivalent readiness signals and sets status.selfInitialized.
• Once initialized, the infrastructure manager scales to the requested replica count and later pods auto-unseal and join the Raft cluster.

Self-init changes root-token handling

Self-init requires an auto-unseal mechanism. In exchange, it avoids creating a root-token Secret and keeps bootstrap closer to OpenBao’s native startup path.

Standard init

Standard init flow

• The infrastructure manager still forces single-pod bootstrap and renders TLS, storage, retry_join, and seal configuration first.
• The init manager waits for pod-0 readiness, detects whether the cluster is already initialized, and calls /v1/sys/init only when needed.
• The init response is handled in-memory, the root token is stored in <cluster>-root-token, and initialization status is patched back to the cluster.
• After initialization and autopilot configuration complete, the infrastructure manager scales the StatefulSet to the requested replica count.

Static auto-unseal version requirement

Static auto-unseal requires OpenBao v2.4.0 or later. Older versions need a supported external KMS seal instead of the built-in static seal path.

Reference table

Safety boundaries

Safety boundaries.

Concern	Creation behavior
Split-brain at first boot	The cluster always starts with one replica so only one node can become the first Raft leader.
Root material handling	Standard init stores the root token in a Secret without logging the init response; self-init avoids creating the Secret entirely.
Already initialized detection	The init manager skips the init call when service-registration labels or health prove the cluster is already initialized.
Autopilot baseline	The init manager applies valid autopilot defaults before steady-state operations and later upgrades begin.

Continue the lifecycle

Day 2 operationsMove from first boot into upgrades, maintenance, and the long-running operation model.Init managerOpen the deep dive for the exact initialization, root-token, and autopilot contract.Create your first clusterCompare the internal creation flow with the operator-facing first-cluster guide.