Commercial and technical foundation
A legally separated product boundary and a testable control-plane skeleton.
- Confirm the final brand and domain before public launch
- Pin the supported runtime version and record exact provenance
- Create tenant, user, server, application, and operation models
- Complete the first threat model and dependency policy
Exit evidence: CI passes, the runtime boundary is documented, and no upstream code is presented as original CloudRivet work.
Secure server enrollment
A fresh customer VM can become a known, observable, dedicated runtime node.
- One-time bootstrap token and node identity issuance
- Outbound-only agent connection with certificate rotation
- Supported Ubuntu and Debian admission checks
- Heartbeat, disk, load, and runtime version reporting
Exit evidence: A clean VM enrolls without retaining an unrestricted root credential and appears healthy in the control plane.
Daily application operations
Customers can safely run the common application lifecycle without a shell.
- Typed and allowlisted agent actions only
- Apps, configuration, domains, TLS, logs, restart, and scale
- Secret write paths with redacted reads and logs
- Idempotency keys, expiry, audit events, and clear failures
Exit evidence: Representative apps complete the full create-to-deploy lifecycle and arbitrary command execution is absent.
Git delivery and revenue loop
A design partner can connect code, deploy it, and enter a paid managed-service relationship.
- GitHub App installation and signed webhook intake
- Deployment queue, history, logs, and rollback metadata
- Plan entitlements and server allowances
- Human-led onboarding and support runbook
Exit evidence: A Git push produces one traceable deployment and billing failure never destroys or disables a running workload.
Recovery and safe upgrades
The product can prove recovery instead of merely claiming that backups exist.
- Encrypted configuration and PostgreSQL backup beta
- Integrity hashes, retention metadata, and restore drill
- Internal runtime-update canary and post-update checks
- Manual stop and rollback path for a failed rollout
Exit evidence: A fresh target restores from a recorded backup and a failed canary cannot advance to customer nodes.
Design-partner paid beta
A deliberately small cohort pays for managed reliability and produces evidence for the next build.
- Three to ten qualified design partners
- Paid onboarding and managed-operations offer
- Support, incident, privacy, and deletion workflows
- Launch scorecard for activation, deployment, recovery, and support
Exit evidence: At least one real customer completes enrollment, deployment, backup, and support with evidence; public launch remains a separate decision.
Post-MVP, in order
- Team RBAC and durable audit export.
- Managed PostgreSQL and Redis lifecycle.
- Preview environments.
- Enterprise SSO, private networking, and custom retention.
- Dedicated managed hosting after the BYO-server operation is proven.
Explicitly excluded from the MVP
Shared hostile-tenant runtime hosts, arbitrary browser shell access, Kubernetes clustering, sophisticated metrics, custom build systems, enterprise SSO, and unattended fleet-wide runtime upgrades.
For owners, acceptance criteria, and issue links, see the GitHub issue tracker. Repository documents remain the scope baseline; GitHub owns live work state.