docs.shellr.net

Deployment Flow

Build, stage, switch, verify.

The deployment path is intentionally simple: build on GitHub Actions, transfer a release to the VM, validate configuration, update containers, and verify health before a release is treated as complete.

Last reviewed: April 2026 Trigger: GitHub Actions Gate: health checks
Why this choice For a single VM, a readable SSH-based delivery path is easier to review and recover than introducing more moving parts than the platform actually needs.

Sequence

What happens during a release.

  • Changes are pushed to GitHub and picked up by the deployment workflow.
  • Artifacts and images are prepared and transferred to the VM.
  • Compose configuration is validated before the live stack is updated.
  • Services are recreated and health endpoints are checked before the run is considered successful.

Failure Modes

What the process is designed to avoid.

  • Blind overwrite: the deployment path validates and checks health instead of treating container recreation as success.
  • Unclear rollback: releases are staged and rollback-aware, so a bad change does not require improvisation.
  • Operational drift: the same repo structure used for local review maps to the VM layout under /projects/genesis.

Runbook

The first checks after a release.

  • Confirm container health with docker compose ps.
  • Check the public surfaces: shellr.net, dma.shellr.net, and status.shellr.net.
  • Verify Prometheus targets and Grafana health if observability changed.
  • Rollback immediately if the health-gated checks fail instead of waiting for user reports.

Operational Limits

What this deployment model does not try to be.

  • It is not blue-green or multi-node orchestration.
  • It does not hide the production layout behind a control plane.
  • It is intentionally optimized for maintainability on one VM and one operator path.