Step 5

Choose the next operating concern before you walk away.

A working cluster is not the end of setup. The next move should be deliberate: harden it, expose it, wire backups, or move into the operating guides that match the job in front of you.

Open the production checklistOpen Operate

Leave Get Started only when

• the access path and TLS posture are chosen
• backup and restore work has an owner
• the first upgrade will not be improvised
• someone knows which docs section owns the next change

Decision matrix

Recommended first order after the cluster is healthy

Recommended first order after the cluster is healthy.

If this is your situation	Do this next	Why first
Default production rollout	Production checklist	It turns a merely working cluster into one with explicit security, durability, and readiness gates before teams depend on it.
You have not yet proven backup or restore	Backups	The first risky upgrade should not be the first time object storage, backup auth, and restore assumptions are tested.
You need user or edge access now	External access	TLS mode, exposure path, and user auth assumptions should be settled before traffic and clients grow around a temporary shortcut.
You are already planning the first version change	Upgrades	Upgrade strategy and pre-upgrade snapshot expectations need to be deliberate, not improvised after the version field changes.

Pick the next operating concern

1. 01

   Finish the production checklist

   Close the gap between a working cluster and an environment you can responsibly expose and support.

   Open
2. 02

   Expose the cluster safely

   Choose Gateway API, Ingress, or service exposure with the TLS posture your profile actually supports.

   Open
3. 03

   Configure backups and restore readiness

   Wire snapshots before the first risky change so restore is practiced before an incident or failed rollout.

   Open
4. 04

   Plan upgrades and routine operations

   Choose the upgrade strategy, then move into maintenance, troubleshooting, and operating runbooks.

   Open
5. 05

   Onboard tenant namespaces

   Use OpenBaoTenant when the platform team owns the operator and teams consume OpenBao as a service.

   Open

When you need deeper context

Browse validated deploymentsUse tested architectures, recipes, and runbooks when you want a known-good implementation path.Open SecurityReview trust boundaries, guardrails, and profile assumptions before you standardize on this cluster shape.Open ArchitectureUse the internal model when you need to understand why the operator behaves the way it does.