Local development lane with shared edge and RustFS
This validated local baseline covers development work on k3d with a shared terminating edge, operator-managed TLS, RustFS backups, and blue/green upgrades. Use it to exercise the cluster lifecycle with a low-friction local topology.
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
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
| 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 baseline covers snapshot behavior against a real object-storage boundary without cloud credentials. |
| Upgrade model | upgrade.strategy: BlueGreen | The 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
| 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 exercises snapshot upload and retention behavior against an S3-compatible API. |
| 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. |
Baseline requirements
- 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 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
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.