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):
- The agent fetches
/update/manifest.jsonand compares the advertised
- If a newer version applies, it downloads the artifact for its component and
- It checks the download's sha256 against the manifest, then verifies the
- It applies the new binary with an atomic temp-file write +
rename()in
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.