Skip to main content
Version: next

This lane proves

  • a Development-profile cluster can bootstrap cleanly on k3d without extra cloud dependencies
  • the shared terminating edge can front OpenBao alongside the rest of the local platform toolchain
  • operator-managed TLS, self-init, JWT bootstrap, and RustFS backups can coexist in one repeatable lane
  • blue/green upgrades can be rehearsed locally before you touch a hardened or cloud baseline
Classification

Local reference architecture. k3d is not a production target, but this lane is the preferred proving ground for local operator bring-up, UI checks, backup rehearsal, and upgrade behavior.

Decision matrix

Lane summary

Lane summary.
SurfaceChoiceWhy it matters
TLS modelspec.tls.mode: OperatorManagedThe operator owns the internal server certificate path so the lane can stay self-contained.
Edge modelShared terminating Gateway API edgeThe same local edge can front OpenBao, ArgoCD, Grafana, and other tools without a dedicated passthrough stack.
Backup targetRustFS via the S3-compatible APIThe lane proves snapshot behavior against a real object-storage boundary without needing cloud credentials.
Upgrade modelupgrade.strategy: BlueGreenThe lane doubles as a low-risk rehearsal environment for upgrade orchestration and cutover behavior.

Diagram

Validated lane topology

The shared terminating edge stays simple, the operator owns TLS and bootstrap, and the backup path leaves the cluster through a separate RustFS boundary.

Why this lane exists

Reference table

Key design choices

Key design choices.
ChoiceWhat it optimizesWhy it stays in the lane
RustFS for backupsA real S3-compatible transfer boundary with no cloud dependency.The lane should prove snapshot upload and retention behavior, not just configuration syntax.
Blue/green upgradesUpgrade behavior can be rehearsed locally before a hardened rollout.The development lane is where you want fast iteration on rollout logic and status transitions.
Optional demo loginUI access stays easy during development and demos.It is a convenience for local validation only and should never be mistaken for a production auth pattern.

Stay on the validated path

  • keep spec.profile: Development and do not treat the lane as a production hardening reference
  • keep the shared terminating Gateway in front of the cluster instead of switching to passthrough mid-lane
  • keep the RustFS endpoint reachable from the tenant namespace and use a dedicated backup Secret
  • treat the demo userpass login as local-only convenience and remove it from any shared environment
  • disable AppArmor only when the local runtime requires it and document that as a node limitation, not a preferred default
What this lane validated

The local development lane exercised self-init bootstrap, JWT admin login, optional demo UI login, shared-edge exposure, scheduled and manual backup behavior to RustFS, and blue/green upgrade rehearsal.

What this lane is not

This is not a production reference, not a hardened security posture, and not proof that the shared terminating edge is the right answer for public OpenBao endpoints. It is a fast, realistic local validation lane.

Use the lane

Next release documentation

You are reading the unreleased main docs. Use the version menu for the newest published release, or check the release notes for what is already out.

Was this page helpful?

Use Needs work to open a structured GitHub issue for this page. The Yes button only acknowledges the signal locally.