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, one download per supported architecture. There is nothing else to fetch: everything the agent needs on the node comes with 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: the files of a release that has already gone out are never replaced.

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 written 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):

The agent fetches /update/manifest.json and compares the advertised version against what it is running and against its monotonic version floor (see below).
If a newer version applies, it downloads the artifact for its component and architecture over HTTPS.
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.
It swaps the new version in as a single step — there is never a half-written agent on disk — then restarts under the watchdog.

Because packet forwarding does not depend on the agent process and the interfaces stay in place 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

Updating the members of a cluster

Each member of a cluster updates itself like any other node; there is no cluster-wide rollout. While a member restarts for an update the others list it as not answering for a moment, and the cluster keeps working. A member running a release the others cannot manage — much older or newer — is listed as such, with a link to its own console, until the members are on releases that work together again. To update by hand, run cenvero-str-ctl update apply on one member at a time, so most voting members stay up.

Forming or joining a cluster needs agent 1.0.0-rc.81 or later on the node.

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.

↓ This page as JSON ↓ All documentation as JSON