Upgrades

Stratum upgrades are pull-based and cryptographically verified. The management panel publishes releases; each agent polls a signed manifest, and when a newer, complete release is available it downloads, verifies, and applies the artifacts itself. There is no push, no heartbeat-driven rollout, and no central scheduler — every node updates on its own poll loop.

Releases

A release bundles the agent (and the CLI) at a pinned version. The agent's embedded eBPF programs, watchdog, and kernel-module source travel inside the agent binary, so a release advertises the binaries CI uploaded for it.

A release becomes visible to agents only when it is published and complete — every required (component, architecture) artifact is present and carries a publisher signature. A half-published or unsigned release is never advertised, so an agent never pulls an incomplete set. Once published, a release is immutable: CI cannot replace the artifacts of a release that has already gone out.

Release channels (stable, beta, RC)

Every release ships on one of three channels: stable, beta, or rc (beta and RC together form the pre-release track). The channel comes from the release tag — vX.Y.Z is stable, vX.Y.Z-beta.N is beta, vX.Y.Z-rc.N is rc.

Pre-release builds require a pre-release license (see Licensing), and the gate is strict in both directions:

• a stable license is served — and can run — only stable builds;
• a pre-release license is served — and can run — only beta/RC builds, never stable.

This is enforced at every layer: the manifest only advertises releases on the channel your license is entitled to, the /download route returns 404 for any out-of-channel build (so a stable key cannot even fetch a beta binary), and the channel is baked into the signed license, so the agent refuses to run a mismatched build even offline.

The update manifest

Agents read /update/manifest.json from the panel. The manifest is license-gated (the same valid-license check as the installer), and it advertises the highest complete published release on the channel your license is entitled to (see Release channels above), by semantic version — not simply the most recently published one. Each artifact entry carries:

• a license-gated download URL on the panel,
• the artifact's sha256,
• a detached Ed25519 publisher signature over the binary's bytes, and
• the publisher key id.

How a node updates

Each agent runs a long-interval poll loop (it checks infrequently; every tick is a no-op unless a newer, fully verified build exists):

1. The agent fetches /update/manifest.json and compares the advertised

version against what it is running and against its **monotonic version floor** (see below).

1. If a newer version applies, it downloads the artifact for its component and

architecture over HTTPS.

1. It checks the download's sha256 against the manifest, then verifies the

manifest's Ed25519 signature over the downloaded bytes against its compiled-in publisher public key. Anything that fails verification is discarded — nothing unsigned or altered is ever installed.

1. It applies the new binary with an atomic temp-file write + rename() in

place, then restarts under the watchdog.

Because the data plane is eBPF and the interfaces are held by the kernel module, the brief agent restart does not tear down existing flows.

Downgrade protection

The agent keeps a monotonic version floor persisted in /var/lib/cenvero-str/. After a successful apply it raises the floor to the version it just installed, and it refuses any update at or below the floor. A panel that is tampered with (or rolled back) to advertise an older version cannot walk an agent backwards. The panel enforces its own floor as well (updates.min_version), so both sides agree on the lowest acceptable version.

Self-rollback on a failed apply

Applying an update is local to the node and self-healing: before swapping the binary the agent keeps a backup of the previous one. If the post-restart health check does not pass, the agent restores the previous binary and brings it back into service. This is a single-node safeguard around its own apply step — there is no fleet-wide automatic revert and no canary/percentage rollout orchestrated from the panel.

Checking versions

# What's installed now
cenvero-str-ctl status

# Ask the agent to check the manifest for a newer release
cenvero-str-ctl update check

# Apply an available update now (otherwise it applies on the next poll)
cenvero-str-ctl update apply

Relationship to licensing

The update manifest and the artifact downloads require a valid license, just like the initial install. A node in the Frozen license state keeps running its current version but cannot pull new updates until the license is renewed — see Licensing.

Next steps

• Installation — the initial install flow.
• Plugins Overview — extending a node beyond the core.