Roadmap relationship
Outcome
Deploy and operate multi-service applications from Compose-compatible definitions, and offer a curated, versioned template catalog that produces inspectable configuration rather than opaque installations.
Current gap
ts-cloud can deploy sites, serverless functions, and containers, but lacks a first-class multi-service Compose model, import/conversion workflow, per-service operations, or template catalog. Complex application stacks therefore require manual infrastructure composition.
User experience
- Create/import Compose from a repository, pasted/uploaded file, or template; preview parsed services, ports, volumes, networks, dependencies, variables, and unsupported fields before deploy.
- Provide a topology-oriented stack overview plus per-service status, logs, shell, domains, configuration, deployments, and volumes.
- Template cards show source/version, required inputs, architecture, minimum resources, exposed services, maintenance notes, and last verification.
- Upgrades show a manifest/config diff and allow pinning; user changes are preserved explicitly.
Scope
- Define a Compose application manifest with services, images/builds, commands, health checks, dependencies, networks, named volumes, secrets/configs, resource limits, restart policy, and domains.
- Parse a documented Compose-spec subset with actionable diagnostics and an export/round-trip path.
- Deploy to capable server/fleet drivers and map supported portions to AWS container orchestration where appropriate.
- Support start/stop/redeploy, ordered logs, per-service shell, scale where capable, and stack-wide deletion.
- Create a versioned template registry format, validation pipeline, health smoke tests, categories/search, and local/custom catalogs.
Technical direction
- Keep original source plus normalized manifest and record conversion warnings.
- Use dependency ordering and health gates without assuming
depends_onimplies readiness. - Namespace resources deterministically by project/environment/stack and preserve volume identity across releases.
- Templates resolve to normal manifests and never bypass validation, authorization, audit, or deployment queues.
Safety and operability
- Block privileged containers, host mounts/networking, device access, and unsafe capabilities by default; require explicit policy exceptions.
- Never render secret values in converted files, diffs, logs, or template metadata.
- Deletion separates stateless services from persistent volumes and requires resource-name confirmation for data removal.
- Pin template/image versions or clearly flag floating tags.
Acceptance criteria
- A representative web+worker+Postgres+Redis stack can be imported, previewed, deployed, observed, redeployed, and removed while preserving or explicitly deleting data.
- Unsupported Compose keys fail or warn before provider mutation according to documented severity.
- A template deploy produces the same editable manifest as manual creation.
- Per-service domains, health, logs, and shell obey permissions and provider capabilities.
Verification
- Compose parsing/round-trip fixtures, dependency/health ordering, resource naming, and destructive-volume tests.
- Template schema, signature/source metadata, version upgrade, and smoke-test CI.
- End-to-end multi-service deployment on at least one server driver.
Non-goals
- Perfect compatibility with every Docker Compose extension.
- Running arbitrary unreviewed remote template scripts with control-plane credentials.
- Replacing Kubernetes.