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.

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.

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

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: 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

Deployment recipeReproduce the exact development lane with tenant onboarding, self-init, shared-edge exposure, and RustFS backups.Backup operationsReview the generic backup model behind the RustFS portion of this validated lane.Get StartedUse the operator onboarding path when you need the product-wide default workflow instead of a validated local lane.