Skip to main content
Version: 0.2.x

Validated coverage

  • 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 moving to a hardened or cloud baseline
Baseline scope

This local reference architecture uses k3d as a development environment for operator bring-up, UI checks, backup rehearsal, and upgrade behavior. It is a validated local lane rather than a production target.

Decision matrix

Baseline summary

Baseline 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 baseline covers snapshot behavior against a real object-storage boundary without cloud credentials.
Upgrade modelupgrade.strategy: BlueGreenThe lane doubles as a low-risk rehearsal environment for upgrade orchestration and cutover behavior.

Diagram

Baseline 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 exercises snapshot upload and retention behavior against an S3-compatible API.
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.

Baseline requirements

  • 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
Validated coverage

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.

Out of scope

This lane does not define a production reference or a hardened security posture. It is a local validation environment for shared-edge routing, backup behavior, and upgrade rehearsal.

Next steps

Published release documentation

You are reading docs for version 0.2.x. Use the version menu to switch to next or another archived release.

Was this page helpful?

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