ReaperCI Documentation

ReaperCI documentation

Invite-only beta operations handbook

The beta is a design-partner program, not a production SLA. It validates the complete Git-to-approved-VPS loop with 10-20 teams while preserving a safe exit path for every participant.

Entry criteria

A beta release candidate must have no known critical/high security issue, no open P0/P1 data-loss, secret-exposure, or deployment-safety defect, a successful amd64 and arm64 Linux smoke, a complete backup/restore drill, and a documented one-version rollback. The installer, migration guide, threat model, operations checklist, incident runbook, and connector guide ship with the same commit. The isolated release capacity profile must also pass and its JSON result must be attached to the release validation record.

Partner onboarding

  1. Record the team's repositories, VPS count, architecture, current delivery path, acceptable test environment, and named technical contact.
  2. Agree that production use is optional and unsupported during beta. Identify the fallback deployment path before installation.
  3. Choose self-hosted or an isolated managed stack. Never place beta customer builds on Echo or another shared edge.
  4. Measure install time from the first documented command to a healthy login.
  5. Connect or create one repository and measure time to the first provider status or native push build.
  6. Add a staging server, health check, approval, deployment, live-state inspection, and rollback.
  7. Enroll an agent service account with the smallest scopes, run one-call build triage, and confirm its audit identity and inability to approve production.
  8. Complete a backup and explain how the partner can leave with all customer data.

Never ask a partner to send a token, private key, .env file, master key, raw database, or unredacted build log. Use screen sharing or customer-run diagnostic commands when sensitive context is required.

Weekly cadence

  • Monday: review incidents, security findings, onboarding funnel, restore evidence, and the highest-friction workflow.
  • Tuesday-Thursday: ship bounded fixes behind the required release gates and conduct onboarding or workflow interviews.
  • Friday: publish a private release candidate, upgrade internal and disposable partner-like stacks, run restore/rollback, and send concise release notes.

Every partner interview captures the intended job, exact point of confusion, time lost, workaround, severity, and whether the problem prevented a successful build or deployment. Prioritize repeated blockers over requested breadth outside the Docker/Compose VPS lane.

Metrics

Track only operational product events needed for beta decisions. Prefer aggregated counts and durations; do not collect repository content, source code, secret values, build log bodies, command output, or customer application data.

  • install-to-healthy duration;
  • repository connection duration and provider;
  • first successful build and deployment timestamps;
  • rollback completion and health result;
  • weekly active workspace count;
  • build outcome excluding user-code failures;
  • connector online/offline duration;
  • support category and time to resolution.

The beta gate is median install under ten minutes, median repository connection under five minutes, 80% of invited teams completing a build and deployment, and 60% remaining weekly active after four weeks.

The scoped usage:read snapshot at GET /api/v1/usage provides the privacy-safe product portion of this evidence. Build and deployment counts use the requested half-open reporting window (periodStart <= finishedAt < periodEnd). A failed build is a user-code or pipeline-step failure; infra-error is a ReaperCI/platform failure. Pipeline execution reliability is therefore (successfulBuildCount + userCodeFailureBuildCount) / (successfulBuildCount + userCodeFailureBuildCount + infrastructureErrorBuildCount). Canceled or incomplete builds are excluded.

The snapshot also returns lifetime activation timestamps for the first repository, successful build, and successful deployment plus the latest repository, push, build, or deployment activity. These fields contain no repository name, commit, source, log, or actor data. Managed Cloud stores only these aggregates. Self-hosted partners can inspect or export the same snapshot without enabling telemetry. Install timing, provider-specific connection timing, support resolution, and cohort/commitment evidence remain explicit operator records; they must not be inferred or fabricated from product events.

Release and incident practice

Every beta release has an immutable version, checksums, SBOM/provenance where available, upgrade notes, known issues, backup compatibility statement, and the last green validation record. Keep the immediately previous version and restore artifact available.

Use the incident response runbook for any suspected data, secret, or deployment safety issue. Pause onboarding after a SEV-0/SEV-1 until containment and partner communication are complete. Do not hide beta incidents to protect launch timing.

Exit criteria

Proceed toward public GA only after at least 15 teams are active, five have committed to paid conversion, managed provisioning no longer requires manual host access, valid pipelines complete correctly at least 99% of the time excluding user-code failure, managed RPO/RTO drills meet 4 hours/2 hours, and security, legal, billing, public documentation, and reproducible release gates are closed.