Roadmap relationship
Outcome
Introduce a durable, versioned local control-plane store that survives dashboard restarts and can safely support projects, users, deployments, operations, audit records, provider connections, and fleet inventory without turning cloud.config.ts into an opaque database.
Current gap
Dashboard identity is stored in JSON files, several managers keep state only in memory, and long-running actions are spawned directly from HTTP requests. This cannot support durable queues, searchable history, multi-project navigation, reliable cancellation, or migrations.
User experience
- First startup performs an explicit, observable initialization; upgrades show migration progress and a recoverable failure state.
- The dashboard distinguishes desired config, discovered provider state, and control-plane metadata; drift is visible rather than silently overwritten.
- Operators can inspect storage health, schema version, last backup, and pending/retryable operations from diagnostics.
Scope
- Define normalized entities for projects, environments, services/resources, deployments, operations, events, actors, credentials metadata, and settings.
- Use an embedded transactional store with WAL/concurrency behavior suitable for one dashboard process; provide repository interfaces so a remote store can be added later.
- Add forward-only numbered migrations, startup locking, backup-before-migrate, integrity checks, retention/compaction, and an export/import command.
- Move in-memory preview/deployment/operation state and dashboard user metadata behind repositories incrementally; retain config as desired-state input.
Technical direction
- Add stable opaque IDs, timestamps, correlation IDs, idempotency keys, optimistic concurrency/version columns, and sanitized JSON payloads.
- Model operations as a state machine (
queued,running,succeeded,failed,cancelled,timed_out) with append-only events. - Provide transaction boundaries and adapters that can be unit-tested without provider access.
- Document ownership: CloudFormation/provider APIs remain infrastructure truth; the store records control-plane intent, metadata, and history.
Safety and operability
- Set restrictive filesystem permissions; never persist plaintext secrets or unredacted command output.
- Make migrations crash-safe and idempotent, refuse unsupported downgrades, and keep a documented restore path.
- Enforce bounded event/output sizes and retention so a noisy workload cannot exhaust the box.
Acceptance criteria
- Restarting during or after an operation preserves its record and deterministically marks/reconciles orphaned work.
- Two concurrent mutations cannot silently overwrite the same resource.
- A migration failure leaves the prior database recoverable and dashboard diagnostics explain remediation.
- Config-only users can continue using the CLI without starting a dashboard database.
Verification
- Migration upgrade/rollback-fixture tests across every schema version.
- Concurrent writer, crash/restart, corruption detection, retention, permission, and redaction tests.
- End-to-end restart test covering a queued and a running operation.
Non-goals
- Replacing CloudFormation or provider APIs as infrastructure state.
- Building a multi-node distributed database in this issue.
- Persisting secret values or unrestricted terminal transcripts.