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 ships as a single self-contained 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 checksum, and
• a publisher signature that proves the binary was released by Cenvero and

has not been altered.

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

binary's publisher signature. 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 runs in the kernel and the interfaces stay held across the swap, the brief agent restart does not tear down existing flows.

Configuration an update migrates for you

An update can carry a settings change the agent applies to itself, so a node does not need an operator to keep working. There is one of those in this version.

Compute mode has been removed, and nodes on it migrate automatically. Older versions asked a node to be either a Compute node or a Gateway node; every node now routes. A node updating from an older version has its configuration rewritten for it as part of the update — no reinstall, nothing to set, and no interruption beyond the usual restart. Its networks, endpoints, firewall rules, tenants and addressing carry over untouched. See Nodes and Interfaces.

Downgrade protection

The agent keeps a monotonic version floor persisted on disk. 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 minimum-version floor as well, 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.