Updates¶

What this page shows¶

Select Updates in the sidebar to see the software update status of the node you are connected to and every node below it in the chain. Each node gets its own card: the version it is currently running, its update channel, when it last checked for updates, and any release newer than what it is running. The summary bar at the top folds the whole chain into one line. A node that is not responding shows its last-known status marked with when it was read, and a node whose software predates update reporting shows a short note instead of a status.

Apply and Revert also act on a downstream node, from this console. Select them on that node's own card the same way as on this node's, and the card shows a waiting state carrying its own wait window until the node reports back.

Feed and manifest¶

A node either polls an update feed itself, or holds a manifest couriered down to it from a node above it in the chain - either way, "manifest" means the same signed document describing what releases exist. A node with neither shows no update feed configured.

Once a manifest has been read, its card shows checked <time> ago. A manifest that has gone stale - older than expected for how often the node is set up to check - is marked manifest stale: the feed may be unreachable or withholding updates, worth a look even though nothing has failed outright. A node's own last check failure, when it has one, is shown as reported.

Checking for updates now¶

This console checks its own update feed on a schedule; select Check for Updates, near the top of this page (Administrator only), to check right now instead of waiting for it. It works whether or not the automatic check is switched on: the check builds its own feed client from this node's configured address and channel (or the defaults, if neither is set) regardless.

While the check runs the button reads Checking... and is disabled. Once it answers, one line appears under it: no updates are available or version <v> is available, stamped with the time it finished. A successful check refreshes this page's status at once, so the card above reflects it without a manual reload.

If the very first attempt gets no answer at all, the button retries once on its own after a short pause, staying on Checking... the whole time; only a second no-answer in a row is actually reported.

A check already running, an unreachable update server, or a manifest this console does not trust are each reported with their own sentence, and the button is available again as soon as it answers either way. When there really is no answer, check the internet connection or try again later.

After two checks in a row the node waits progressively longer before it accepts another, and the page says how long.

An Administrator sets this node's update feed in the Update feed panel on this page: the server address (the default is filled in), the channel (stable or beta) and whether the node checks on a schedule. Saving asks for a reason when this node's audit trail is on. Other users see the channel only. There is no update feed setting on the Settings page, and no chain-wide feed setting.

Available releases¶

Each release newer than the running version is listed with its version number, a severity chip (security, bugfix, or feature), its release date, its download size, and its release notes. A release that requires a restart to apply says so. A release this node cannot currently apply - for example a hardware or platform mismatch - shows the reason instead of a working control.

An unrecognized severity from a newer node is shown by its raw name rather than hidden.

Applying an update¶

Select Apply on this node's own card (Administrator only) to install a release listed above. Applying first downloads and verifies it - the bytes are checked again, as root, before anything is installed - then asks the host to install what it staged. Installing an update restarts this node. The confirmation names the estimated downtime and warns that every reverse-connect uplink drops and re-dials during the restart, so data from every node below this one reads Bad until the links are back; a store-and-forward buffer keeps its spooled records and resumes once the restart completes.

While the update runs, the card shows an Installing notice in place of the controls and the console reconnects and reports the outcome on its own - there is nothing further to do.

The button is unavailable, with a note explaining why, when this caller does not have write access on this node, when a request is already pending, or when the release itself cannot be applied here.

Updates are never installed automatically. An Administrator must apply each update from this page.

Reverting an update¶

Select Revert on this node's own card (Administrator only) to return it to the version it ran before the last update. A revert restores the running version only; configuration is left as it is. Reverting restarts the node with the same reverse-connect warning as applying an update.

The button is unavailable, with a note explaining why, when this caller does not have write access on this node, when a request is already pending, or when no previous version is held here to revert to.

The reported outcome¶

Once the host has something to report, this node's card shows one line naming what happened: updated to or reverted to a version for a clean success, the same wording with a warning that the node has not reported healthy when the restart finished but the node's own health has not come back nominal since, rolled back naming the reason when an update failed and the host restored the previous version on its own, or failed naming the reason when it could not even be rolled back. The line stays until the next apply or revert replaces it.

A downstream node's card reports its own outcome the same way, once something has run on it from here.

If this node does not come back¶

After dispatching an apply or revert, the console waits for this node to reconnect: up to three times the release's own estimated downtime, floored at 3 minutes and capped at 15. If nothing has come back by the end of that window, the card says the node did not report back and the controls return. Recovering a node that never comes back is the documented SSH runbook on the host, not something this console can do for you.

A downstream node waits differently: see What still applying means.

Delivering to a downstream node¶

Select Deliver on a downstream node's own card (Administrator only) to send a release already held here down to that node, without installing it. Deliver first reads the path to that node and lists every node along the way: its free space and whether it already holds the release, so nothing moves as a surprise. Confirming with a reason starts the transfer.

Delivering and applying are kept separate on purpose. Moving software onto a node and restarting it are two different decisions, so this console asks for both, one at a time, rather than one action doing both.

If the chain has changed by the time the transfer actually runs, the card says so and asks you to check the hop list again before delivering once more.

While a delivery to a node is in progress, its card shows a progress bar for the transfer, and its Deliver, Apply and Revert are disabled until the transfer finishes. Apply on a downstream node also needs a copy already delivered to it: until this console has sent the exact version down, Apply stays disabled and says so.

A Cancel delivery button appears beside the bar while the transfer is running (Administrator only); confirming with a reason discards the partial artifact already on the node, applies nothing, and lets Deliver be started again afterward.

Manual update from a file¶

On a chain that cannot reach the update feed, select Manual update (Administrator only, on the node you are connected to) to install a release from a file instead. The file is a signed Flowgate update bundle ending in .fgu, one per release and platform: a Linux bundle for nodes running the Docker image, and a Windows bundle for nodes installed with the Windows installer.

The upload needs HTTPS. When this console reaches the node over plain HTTP the button is unavailable until management TLS is turned on under Settings; a bundle is never sent in the clear.

Pick the bundle, pick the node it is for (this node, or a node below it), and confirm with a reason. The bundle is uploaded to this node, which checks that it is a genuine Flowgate release before keeping anything: first the signed manifest inside it, then the package itself. A bundle whose manifest is older than the one this node already holds is refused, so an old file cannot roll back the chain's view of which releases exist. A manifest past its expiry date is still accepted, with a warning: the signature and the serial are what protect you, so check that it is the release you meant.

The manifest from the bundle is also passed down to the nodes below this one, so each of them lists the release as available, the same as if it had come from the feed. A bundle for a different platform than this node's is kept here only for delivery: the card lists it as held for delivery to nodes of that platform, and this node never applies it.

For a node below this one, select Deliver once the bundle is staged. The path to that node is listed first, before anything moves: every node along the way, its free space, whether it already holds the release, and whether it only carries the copy for a node below it. The list also names the platform of the artifact each hop carries, and warns when this console holds no copy for the target node's platform. Then apply the update from that node's own card, as usual.

An import never applies anything. Apply stays a separate action on each node's own card, with its own confirmation. A node that cannot apply on its platform shows the reason on its card instead of an Apply button.

Abort upload stops an upload in progress. If the connection drops during an upload, the dialog says the upload did not complete: check this node's card for a staged version before uploading again.

Applying and reverting a downstream node¶

Select Apply or Revert on a downstream node's own card (Administrator only), the same way as on this node's own card. Apply needs the release already delivered to that node; a version not yet held there shows the reason instead of a working button. Revert returns the node to the version it ran before its last update, the same as it does here, and restores no configuration.

Both restart the node. While the action runs, the card shows an Installing notice in place of the controls, and the console reconnects and reports the outcome on its own.

What still applying means¶

After dispatching an apply or revert on a downstream node, the console waits for that node to reconnect and report what happened, a little longer than it waits for this node's own restart, up to 20 minutes, to allow time for the node to redial this console afterward. If nothing has been reported by the end of that window, the card says the node may still be applying, not that anything has gone wrong.

This is deliberate. The node's own host allows itself more time to finish a restart than this console waits before it stops watching, so a node that has not reported back yet may simply still be within its own budget. Treating that silence as a bad outcome would risk acting on a node that is about to recover on its own. If a node genuinely does not come back after a good while, check it directly, or use the SSH runbook.

What a missing host updater means¶

Applying or reverting a node depends on a small program running on that node's own host, separate from Flowgate itself. A node's card carries a warning when this console has no evidence that program has run there recently: evidence, not a guarantee, since the console is only reporting what the node itself told it.

This warning never blocks a direct Apply or Revert from that node's own card here; the node may still be able to apply the update itself.

The shared updater¶

Each machine has one updater program, shared by the products installed on it. Every node's card has an Updater row that says which one serves the machine: Updater 1.0.0 for the shared updater, Legacy updater for an older per-product one, No host updater has stamped this machine, This node predates the shared updater, or Updater status unknown when the node did not say. Unknown is never read as supported, and none of these is a failure of the node.

When the node can bring the updater to a newer version, the row adds Updater 1.0.1 available. On this node's own card, Apply updater (Administrator only) installs it. The button is unavailable, with a note, when this caller does not have write access, when a request is already pending, or when that version is not yet staged on this node for its platform. The confirmation asks for a reason when this node's audit trail is on or its state is unknown, and the reason is mandatory then.

Applying the updater does not restart this node. The updater replaces itself while the node keeps running, so there is no waiting notice and no reconnect. The row shows Updater update pending until the host answers, then Updater updated to the new version, Updater already current (nothing needed doing), Updater update did not complete. Try again. (nothing was replaced, and the button stays available), or Updater update failed naming the reason.

A legacy updater has no button. On Windows the next product update replaces it; on Linux, installing the h2-updater package does. A downstream node's card shows the same row, read-only: its updater is not updated from this page in this release.

What this release does not do¶

No configuration restore from the console. A revert changes only the running version; restoring configuration from before an update is a host-side step, not a console control.
No downgrade through Apply. Once a node has reached a version, Apply refuses to install anything older than that. Returning to the version before the last update is what Revert is for.
Nothing runs on its own. Delivering, applying and reverting all need an explicit action from an Administrator here. There is no schedule, no automatic download and no unattended apply anywhere on this page.
A reason only when it is recorded. The confirmations on this page, including saving the update feed, ask for a reason only when an audit trail would record it: this node's trail is on, or, for an action on a downstream node, that node's trail is on or cannot be read. When it is asked for while this node's own trail is on, it is mandatory for saving the feed, uploading a bundle, delivering, cancelling a delivery, and applying or reverting on a downstream node. It is optional for this node's own Apply and Revert unless this node requires a reason for every change, and optional when only a downstream node's trail would record it, unless that node refuses the change without one. See Audit.
Each node is updated from its own card: deliver first, then apply. See the Troubleshooting page for what each step did.
No apply from an import. Uploading a bundle verifies and stages it, and passes its manifest down the chain; it never installs anything. Apply stays a separate action on each node's card.
No updater apply on a downstream node yet. The Updater row on a downstream node's card is read-only.

Licensing: the same per-node, capability-gated pattern this page follows, for license status instead of update status.
Getting Started: what each area of the console is for.