Skip to main content

​
Public Support Matrix

This matrix sets expectations for public self-serve StacyVM installs. It separates generally supported workflows from host-gated runtime certification so operators know what can be used immediately, what must be validated on their own infrastructure, and what remains experimental.

​
Support Levels

​
Runtime And Deployment Matrix

​
Public Install Requirements

Before treating a self-serve install as supported, operators should capture:
  • Release verification output from scripts/post-release-validate.sh <version> or installer output with Sigstore verification.
  • stacyvm config lint --production --file <config> output with production environment variables loaded.
  • Confirmation that server.cors_allowed_origins contains exact trusted origins, not *.
  • stacyvm upgrade rehearse --config <config> --database <db> output before binary or image replacement.
  • stacyvm doctor --production output from the target host.
  • stacyvm support bundle --output support.json when opening a support issue.
  • Runtime certification output for gVisor, Kata, Firecracker, or PRoot hosts.
  • Worker identity certification output from scripts/certify-worker-identity.sh <worker-id> --format markdown --output worker-identity-certification.md for multi-worker previews.
  • Evidence that externally issued worker token files refresh before expiry when workers rely on stacyvm worker --worker-token-file instead of local signing keys.
  • Public readiness evidence from scripts/public-readiness-evidence.sh --output public-readiness-evidence.md.
GitHub bug and production support issue templates ask for this same evidence. Reports without the relevant artifacts may need an extra triage round before maintainers can reproduce or classify the issue.

​
Known Public Limitations

  • SQLite is the supported single-node store. Postgres-backed cluster semantics exist, but multi-worker production still requires deployment-specific Postgres contract evidence and backup/restore rehearsal.
  • API keys and admin keys are the primary auth path for single-node deployments. OIDC/JWT RS256 Bearer token auth with JWKS is implemented for enterprise multi-tenant deployments (auth.oidc_enabled, auth.oidc_issuer, auth.oidc_jwks_url). OIDC group-to-role mapping covers viewer, operator, admin, and tenant_admin roles.
  • Docker/runc is convenient and supported with hardened settings, but it is not equivalent to VM isolation.
  • Firecracker production readiness is host-gated because KVM, kernel, rootfs, agent, and networking setup vary by host.
  • PRoot is useful where Docker/KVM are unavailable, but it should not be presented as a production isolation boundary.
  • Release signatures prove artifact provenance from the StacyVM GitHub Actions release workflow; they do not certify a host runtime.
  • CORS is intentionally wildcard by default for local development, but public browser/API deployments must configure explicit trusted origins and pass production config lint.

​
Post-Tag Release Verification

CI builds release binaries and validates checksums before code is merged into a release branch. After a real version tag is published, maintainers should run the public verifier against the GitHub release assets:
On a clean Linux host, also run the installer in verify-only mode with signatures required:
For a final install smoke, run scripts/install.sh once with default checksum verification and once with STACYVM_REQUIRE_SIGNATURES=true plus cosign installed.