Use this lane to validate operator bring-up, shared-edge routing, and backup flows without pretending a dev profile is production.
This local baseline is the lowest-friction validated path for development work on k3d. It keeps the edge simple, keeps TLS operator-managed, keeps backups pointed at an S3-compatible store, and still exercises the cluster lifecycle with a realistic control-plane shape.
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
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
| Surface | Choice | Why it matters |
|---|---|---|
| Profile | spec.profile: Development | The lane is intentionally optimized for speed and validation coverage, not a production-ready posture. |
| TLS model | spec.tls.mode: OperatorManaged | The operator owns the internal server certificate path so the lane can stay self-contained. |
| Edge model | Shared terminating Gateway API edge | The same local edge can front OpenBao, ArgoCD, Grafana, and other tools without a dedicated passthrough stack. |
| Backup target | RustFS via the S3-compatible API | The lane proves snapshot behavior against a real object-storage boundary without needing cloud credentials. |
| Upgrade model | upgrade.strategy: BlueGreen | The 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
| Choice | What it optimizes | Why it stays in the lane |
|---|---|---|
| Shared terminating edge | Fast local bring-up with one ingress surface for multiple tools. | This keeps the lane practical for day-to-day operator work and avoids dedicating a separate passthrough edge to a dev profile. |
| RustFS for backups | A real S3-compatible transfer boundary with no cloud dependency. | The lane should prove snapshot upload and retention behavior, not just configuration syntax. |
| Blue/green upgrades | Upgrade 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 login | UI 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: Developmentand 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
userpasslogin 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
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.
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
You are reading docs for version 0.1.0. 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.