Roadmap: production-grade application delivery and cloud control plane

Goal

Turn ts-cloud into a production-grade application delivery platform and cloud control plane while preserving its core strengths: TypeScript-first configuration, direct provider APIs, CloudFormation as infrastructure state, server and serverless deployment modes, and a lightweight self-hosted dashboard.

This issue is the canonical roadmap index. It coordinates feature work, UI/UX improvements, safety work, and completion of currently stubbed or placeholder-backed capabilities.

Product principles

1. One mental model: project → environment → service/resource → deployment/operation.
2. Config and UI stay reconcilable: dashboard mutations write through a validated control-plane model and show drift instead of creating hidden state.
3. Safe by default: least privilege, typed confirmations for destructive work, append-only audit, secret redaction, idempotent operations, and recoverable rollbacks.
4. Progress is observable: long-running work has durable state, live output, cancellation semantics, and a post-run record.
5. Provider capabilities are explicit: AWS, Hetzner, local boxes, and future drivers expose supported operations without pretending feature parity.
6. CLI, API, and dashboard converge: the same application services and authorization policies back every interface.
7. Accessibility and responsive behavior are release criteria, not polish added later.

Definition of done for roadmap items

Every implementation issue must include:

• CLI/API/dashboard behavior where applicable;
• authorization, secret handling, audit, and destructive-action safety;
• loading, empty, degraded, error, success, and retry UX;
• unit and integration tests plus at least one realistic end-to-end path;
• documentation, migration/rollback notes, and capability detection;
• telemetry sufficient to diagnose failures without exposing secrets.

Phasing

The roadmap is dependency-ordered:

1. Trustworthy control plane and governance foundations.
2. Git-native application delivery.
3. Runtime operability and data durability.
4. Fleet-scale and regional resilience.

Epics

Phase 1 — Trustworthy control plane

• #133
• #137

Phase 2 — Git-native delivery

• #134

Phase 3 — Operability and data durability

• #135
• #136

Phase 4 — Fleet and resilience

• #138

Critical dependency graph

flowchart TD
  S["#139 Persistent state"] --> IA["#140 Resource IA"]
  IA --> ORG["#142 Organizations/RBAC"]
  ORG --> AUTH["#143 Authentication"]
  AUTH --> API["#144 API/service accounts"]

  S --> Q["#148 Deployment queue"]
  API --> GIT["#146 Git integrations"]
  IA --> WIZ["#147 App wizard"]
  GIT --> WIZ
  GIT --> PRE["#149 Preview environments"]
  Q --> PRE
  WIZ --> COMP["#150 Compose/templates"]
  Q --> REL["#151 Releases/promotion"]

  IA --> RUN["#152 Runtime explorer"]
  Q --> RUN
  RUN --> OBS["#153 Observability"]
  OBS --> ALERT["#154 Alerts/notifications"]
  RUN --> DATA["#156 Data services"]
  DATA --> BACKUP["#157 Backups/restores"]
  API --> SEC["#158 Variables/secrets"]
  RUN --> VOL["#159 Volumes"]
  BACKUP --> VOL

  IA --> FLEET["#160 Fleet inventory"]
  AUTH --> FLEET
  FLEET --> OPS["#161 Real driver operations"]
  FLEET --> CAP["#162 Capacity/builders"]
  Q --> CAP
  CAP --> MR["#163 Multi-region/failover"]
  BACKUP --> MR
  ALERT --> MR
  OPS --> MAINT["#164 Upgrades/DR"]
  BACKUP --> MAINT
  ALERT --> MAINT

Existing issues incorporated

These are tracked as children of the epics above and should not be recreated:

• Dashboard safety and UX: #124, #125, #127, #128
• Audit trail: #126
• Full-stack and test deployment paths: #117, #118
• S3-compatible storage: #116
• Cost/resource visibility: #108, #109, #110, #111, #112, #114

Prioritization rule

P0 items establish correctness, trust, identity, or the deployment execution path. P1 items complete the core product experience. P2 items add scale/resilience once the underlying contracts are proven. Milestone order is meaningful; parallel work is encouraged only where the dependency graph permits it.

Out of scope

• Replacing CloudFormation with a separate state engine.
• Hiding provider-specific constraints behind misleading generic controls.
• Building billing or commercial licensing features.
• Copying another product's visual identity or implementation details.