Roadmap relationship
Outcome
Onboard, validate, categorize, and monitor remote servers from AWS, Hetzner, or an existing SSH-accessible box, with an explicit capability and trust model that later scheduling and lifecycle operations can rely on.
Current gap
ts-cloud can provision AWS and Hetzner compute and target a local box, but dashboard scope is effectively one box and server:list/create/ssh/... commands are placeholders. There is no durable fleet registry, enrollment workflow, validation report, labels/capacity, heartbeat, or ownership boundary.
User experience
- Use a guided add-server flow for provision-new or connect-existing: provider/account, region, address, SSH key/agent, host-key verification, role, labels, and validation.
- Validation reports OS/arch, CPU/memory/disk, network/DNS/time, required tools, ports/firewall, proxy/runtime versions, privilege mode, and remediations.
- Fleet list supports status, provider/region, roles, capacity/usage, hosted services, last heartbeat, maintenance/drain state, security findings, and tags.
- Server detail links workloads, deployments, metrics/logs, services, storage, networking, backups, audit, and supported operations.
- Credential/host-key changes and unreachable servers have clear degraded/recovery flows.
Scope
- Define server identity, provider reference, endpoint, SSH transport reference, roles, labels/taints, capacity, capabilities, heartbeat, validation, and lifecycle status.
- Discover/adopt existing AWS/Hetzner instances and enroll arbitrary compatible Linux boxes without assuming ts-cloud created them.
- Implement connection test, validate, bootstrap/repair plan, heartbeat, drain/uncordon, archive/remove-from-control-plane, and inventory refresh.
- Separate application, build, monitoring, backup, and control-plane roles.
- Add CLI/API/dashboard parity and resource-scoped permissions.
Technical direction
- Drivers return a signed/versioned capability document and validation facts; the control plane stores metadata and observed freshness.
- Pin SSH host keys by default, support rotation with explicit review, and keep credentials as secret references.
- Use stable server IDs independent of hostname/IP and reconcile provider identity changes safely.
- Bootstrap steps are idempotent, versioned, previewable, and recorded as durable operations.
Safety and operability
- Connecting an existing server never mutates it until the bootstrap plan is confirmed.
- Display privilege requirements and refuse insecure SSH defaults unless an explicit audited policy allows them.
- Removal from inventory does not terminate provider resources; termination is a separate exact-target action.
- Cross-organization workloads and credentials cannot share a server unless an explicit isolation policy supports it.
Acceptance criteria
- Operators can provision/adopt one AWS instance, one Hetzner server, and one existing box into a common inventory.
- Validation detects missing/incompatible dependencies and produces actionable remediation without false healthy status.
- IP/hostname changes do not duplicate a known server and host-key changes block until reviewed.
- Unreachable servers remain visible with last-known state and do not block unrelated fleet views.
Verification
- Provider/adopt/SSH transport contract fixtures, identity reconciliation, host-key rotation, heartbeat, and validation tests.
- Authorization and cross-tenant isolation tests.
- End-to-end add → validate → bootstrap → heartbeat → drain → archive flow.
Non-goals
- Automatically taking over every server found in a cloud account.
- Using shared root credentials across the fleet.
- Terminating infrastructure when removing inventory metadata.