Developer documentation

Operations

Recovery, upgrades, backup targets, and remaining hardening work.

Operations follow the same ownership boundaries as the architecture. Some state is authoritative and must be protected. Some state is derived and can be rebuilt. The MVP operational model is still being hardened, but that distinction already guides backup, restore, and upgrade order.

Edge caches are disposable. Databases, LDAP, release origins, and workspace storage are authoritative.

How To Think About Recovery

Recovery should restore the sources of truth first, then rebuild derived serving layers. That means identity, control-plane state, storage, and integration data come before edge cache hydration.

Back Up

• Control-plane database.
• LDAP directory.
• Workspace storage and release origins.
• Nextcloud, Forgejo, and Matomo state.
• Custom domain and certificate state.
• Audit logs.

Restore Order

1. LDAP.
2. Control-plane database.
3. Storage and release origin.
4. Nextcloud, Forgejo, and Matomo.
5. Workspace agents.
6. Edge nodes.
7. Rehydrate edge caches.

Upgrade Order

Upgrade the state owner before the components that depend on its contract. In practice, that means database migrations and the control plane come before agents, workers, OpenResty Lua, and integrations.

1. Control-plane DB migration.
2. Control-plane deployment.
3. Agents and workers.
4. OpenResty/Lua.
5. Integration services.

Remaining MVP 10 Work

• Keep the chart as a local/Talos or migration smoke target where it adds useful coverage.
• Add backup and restore jobs.
• Add metrics, dashboards, and alerts.
• Complete direct-host runtime hardening and keep Kubernetes security review scoped to retained pod-native or local-smoke workloads.