Roadmap: production-grade application delivery and cloud control plane

[chrisbbreuer]

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

• [Epic] Phase 1 — trustworthy control plane and dashboard UX #133
• [Epic] Phase 1 — teams, security and governance #137

Phase 2 — Git-native delivery

• [Epic] Phase 2 — Git-native application delivery #134

Phase 3 — Operability and data durability

• [Epic] Phase 3 — runtime operations and observability #135
• [Epic] Phase 3 — data services, configuration and backups #136

Phase 4 — Fleet and resilience

• [Epic] Phase 4 — fleet, scale 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

Loading

Existing issues incorporated

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

• Dashboard safety and UX: dashboard: confirm tokens use generic verbs instead of the resource name #124, dashboard: consolidate the two confirm patterns into a useOpConfirm composable #125, dashboard: robustness gaps — double-submit, swallowed errors, missing empty states #127, dashboard: accessibility pass + stx hygiene (vanilla JS in templates) #128
• Audit trail: dashboard: no audit trail for destructive actions #126
• Full-stack and test deployment paths: Test deploy: paweldregan.com — keep CloudFront/S3 frontend, add Lambda-backed /api #117, Deploy a full-stack containerized backend (API + DB + queues + mail + cache) on ECS Fargate, fronted by an existing CloudFront/S3 site #118
• S3-compatible storage: S3Client: accept custom endpoint config (unblocks R2 / MinIO / DigitalOcean Spaces / Backblaze B2 in stacksjs/stacks#1896) #116
• Cost/resource visibility: Implement cost command — current MTD spend + naive linear projection #108, Implement cost:breakdown — N-day window with previous-window trend comparison #109, Implement resources — list AWS resources via Resource Groups Tagging API #110, Implement resources:unused — find idle resources via CloudWatch metrics #111, Implement optimize — opinionated cost-saving recommendations #112, cost:analyze: top egress endpoints (data-transfer cost breakdown) #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.