DocsBook a demo

Platform

Platform overviewArchitectureWorkflow orchestrationGitOps configurationGovernance and AAAAI and MCPKnowledge and contextRuntime and executionEvidence and monitoring

Use cases

All use casesProduction incidentRelease preparationHotfix to productionSecurity scan triage
Why NopsAIIntegrationsSecurity

Resources

All resourcesAI agent governanceMCP governanceMCP securitySelf-hosted platforms
PricingGitHub

Company

How a run worksAboutContactBook a demo

Release integrity and updates

How releases are tagged and published, and how the CLI verifies what it downloads.

ReferenceAdministratorOperator

Key points

  • scripts/release-tags.sh publishes the stable tag set: exact version, latest, major, and major.minor.
  • Container images and the Helm OCI chart publish all four aliases; installers keep exact versions in generated Compose, Helm values, and locks.
  • First-time CLI installs use the latest GitHub Release assets at https://github.com/nopsai/nopsai/releases/latest; extract the binary onto PATH and remove the downloaded archive.
  • CLI archives and SHA256SUMS publish to the nopsai-cli GHCR OCI package, which must be public so nopsai update --version <x.y.z> does not need repository release access.
  • nopsai update --version <x.y.z> is the upgrade path after first install; it downloads the exact OCI package archive and SHA256SUMS, verifies the checksum, then replaces the local binary.
  • nopsai platform upgrade moves an installed platform forward: it reads the install or deployment lock, keeps generated secrets, and blocks a compatibility-series upgrade until the changelog is acknowledged with --accept-series-upgrade.
  • release/compatibility.yaml is read into buildinfo linker flags and Docker build args so binaries advertise the current platform, runner, API, and capability contract.
  • Enterprise mirrors can override the package, repository, or asset base URL without changing the archive naming contract.

Examples

Check what version is running and what it claimsbash
curl -s "$NOPSAI_URL/version" | jq
Result

Product and API versions, supported CLI and runner ranges, capability IDs, and the release manifest digest when one is present. No deployment configuration and no credentials.

How it works

Multi-arch container builds carry org.opencontainers.image.source as both Dockerfile labels and OCI index/manifest annotations so GHCR can associate packages with the source repository. Already-created unlinked packages may still need a one-time settings connection or a delete and republish.

The exact GitHub Release is marked latest, and moving v<major> and v<major>.<minor> release aliases carry compatibility copies of the same CLI assets.

Repository-owned platform release automation lives in release/nopsai-platform-release.yaml.

Implementation evidence

  • doc/release-bundles.md

    Shared build identity, versioned assets, and GitOps release locks.

  • release/compatibility.yaml

    Platform, runner, API, and capability contract.