{
    "product": "Cenvero Stratum",
    "generated_at": "2026-08-03T07:16:47+00:00",
    "format": "cenvero-docs-v1",
    "document_count": 1,
    "documents": [
        {
            "slug": "upgrades",
            "title": "Upgrades",
            "category": null,
            "url": "https://stratum.cenvero.com/docs/upgrades",
            "headings": [
                {
                    "level": 1,
                    "text": "Upgrades"
                },
                {
                    "level": 2,
                    "text": "Releases"
                },
                {
                    "level": 2,
                    "text": "Release channels (stable, beta, RC)"
                },
                {
                    "level": 2,
                    "text": "The update manifest"
                },
                {
                    "level": 2,
                    "text": "How a node updates"
                },
                {
                    "level": 2,
                    "text": "Configuration an update migrates for you"
                },
                {
                    "level": 2,
                    "text": "Downgrade protection"
                },
                {
                    "level": 2,
                    "text": "Self-rollback on a failed apply"
                },
                {
                    "level": 2,
                    "text": "Checking versions"
                },
                {
                    "level": 2,
                    "text": "Relationship to licensing"
                },
                {
                    "level": 2,
                    "text": "Next steps"
                }
            ],
            "word_count": 884,
            "markdown": "# Upgrades\n\nStratum upgrades are **pull-based** and cryptographically verified. The\nmanagement panel publishes releases; each agent polls a signed manifest, and\nwhen a newer, complete release is available it downloads, verifies, and applies\nthe artifacts itself. There is no push, no heartbeat-driven rollout, and no\ncentral scheduler — every node updates on its own poll loop.\n\n## Releases\n\nA release bundles the agent (and the CLI) at a pinned version. The agent ships\nas a single self-contained binary, so a release advertises the binaries CI\nuploaded for it.\n\nA release becomes visible to agents only when it is **published** and\n**complete** — every required (component, architecture) artifact is present and\ncarries a publisher signature. A half-published or unsigned release is never\nadvertised, so an agent never pulls an incomplete set. Once published, a\nrelease is **immutable**: CI cannot replace the artifacts of a release that has\nalready gone out.\n\n## Release channels (stable, beta, RC)\n\nEvery release ships on one of three channels: `stable`, `beta`, or `rc` (beta and\nRC together form the **pre-release** track). The channel comes from the release\ntag — `vX.Y.Z` is stable, `vX.Y.Z-beta.N` is beta, `vX.Y.Z-rc.N` is rc.\n\nPre-release builds require a **pre-release license** (see\n[Licensing](/docs/licensing)), and the gate is strict in both directions:\n\n- a **stable** license is served — and can run — **only stable** builds;\n- a **pre-release** license is served — and can run — **only beta/RC** builds, never stable.\n\nThis is enforced at every layer: the manifest only advertises releases on the\nchannel your license is entitled to, the `/download` route returns `404` for any\nout-of-channel build (so a stable key cannot even fetch a beta binary), and the\nchannel is baked into the signed license, so the agent **refuses to run** a\nmismatched build even offline.\n\n## The update manifest\n\nAgents read `/update/manifest.json` from the panel. The manifest is\n**license-gated** (the same valid-license check as the installer), and it\nadvertises the **highest complete published release** on the channel your license\nis entitled to (see *Release channels* above), by semantic version — not simply\nthe most recently published one. Each artifact entry carries:\n\n- a license-gated **download URL** on the panel,\n- the artifact's **sha256** checksum, and\n- a **publisher signature** that proves the binary was released by Cenvero and\n  has not been altered.\n\n## How a node updates\n\nEach agent runs a long-interval poll loop (it checks infrequently; every tick\nis a no-op unless a newer, fully verified build exists):\n\n1. The agent fetches `/update/manifest.json` and compares the advertised\n   version against what it is running and against its **monotonic version\n   floor** (see below).\n2. If a newer version applies, it downloads the artifact for its component and\n   architecture over HTTPS.\n3. It checks the download's **sha256** against the manifest, then verifies the\n   binary's **publisher signature**. Anything that fails verification is\n   discarded — nothing unsigned or altered is ever installed.\n4. It applies the new binary with an **atomic temp-file write + `rename()`** in\n   place, then restarts under the watchdog.\n\nBecause the data plane runs in the kernel and the interfaces stay held across\nthe swap, the brief agent restart does not tear down existing flows.\n\n## Configuration an update migrates for you\n\nAn update can carry a settings change the agent applies to itself, so a node\ndoes not need an operator to keep working. There is one of those in this\nversion.\n\n**Compute mode has been removed, and nodes on it migrate automatically.** Older\nversions asked a node to be either a Compute node or a Gateway node; every node\nnow routes. A node updating from an older version has its configuration\nrewritten for it as part of the update — no reinstall, nothing to set, and no\ninterruption beyond the usual restart. Its networks, endpoints, firewall rules,\ntenants and addressing carry over untouched. See\n[Nodes and Interfaces](/docs/nodes).\n\n## Downgrade protection\n\nThe agent keeps a **monotonic version floor** persisted on disk. After a\nsuccessful apply it raises the floor to the\nversion it just installed, and it **refuses any update at or below the floor**.\nA panel that is tampered with (or rolled back) to advertise an older version\ncannot walk an agent backwards. The panel enforces its own minimum-version floor\nas well, so both sides agree on the lowest acceptable version.\n\n## Self-rollback on a failed apply\n\nApplying an update is local to the node and self-healing: before swapping the\nbinary the agent keeps a backup of the previous one. If the post-restart health\ncheck does not pass, the agent restores the previous binary and brings it back\ninto service. This is a **single-node** safeguard around its own apply step —\nthere is no fleet-wide automatic revert and no canary/percentage rollout\norchestrated from the panel.\n\n## Checking versions\n\n```bash\n# What's installed now\ncenvero-str-ctl status\n\n# Ask the agent to check the manifest for a newer release\ncenvero-str-ctl update check\n\n# Apply an available update now (otherwise it applies on the next poll)\ncenvero-str-ctl update apply\n```\n\n## Relationship to licensing\n\nThe update manifest and the artifact downloads require a valid license, just\nlike the initial install. A node in the **Frozen** license state keeps running\nits current version but cannot pull new updates until the license is renewed —\nsee [Licensing](/docs/licensing).\n\n## Next steps\n\n- **[Installation](/docs/installation)** — the initial install flow.\n- **[Plugins Overview](/docs/plugins/overview)** — extending a node beyond the core.\n"
        }
    ]
}