mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-27 12:18:59 +00:00
Anso
ecf4dd5d52
Realign tier guards to the user-stated philosophy: Community covers
deploy/monitor at scale plus security basics, Skipper adds automation
and advanced fleet management, Admiral keeps enterprise control.
Community now includes:
- Trivy install / uninstall / update from the Settings Hub (admin role)
- CVE suppressions CRUD (admin role; replicates fleet-wide)
- Manual image scan with vuln, secret, and misconfig results
- Stack-config scan, scan comparison
- Manual fleet snapshots: create, list, view, restore, delete
- Per-node Sencho self-update (Check Updates + per-node Update)
- Fleet Overview search, sort, filters, node-card expand, auto-refresh
Stays paid:
- Scan policies with block_on_deploy enforcement (Skipper+)
- SBOM (SPDX, CycloneDX), SARIF export (Skipper+)
- Bulk Update All across the fleet (Skipper+)
- Scheduled snapshot create (now Skipper, was Admiral)
- Trivy auto-update toggle, fleet-wide policy push (Admiral)
The Settings -> Security tab is unhidden by setting the registry tier to
null. The SecuritySection no longer early-returns a PaidGate; the policy
list, Add Policy button, and policy dialogs are wrapped in {isPaid && }.
The Fleet view drops isPaid gates on the Snapshots tab, Check Updates
button, per-node update handlers, OverviewToolbar grid controls, the
NodeCard expand affordance, and the auto-refresh notice. The
NodeUpdatesSheet receives a canBulkUpdate prop and gates the Update All
button on it. useFleetUpdateStatus and useFleetPolling drop their isPaid
guards so polling runs for Community; useFleetOverview drops the isPaid
wrap on the filter and sort path.
Backend route guards are flipped per the matrix above. The scheduler
tick and requireScheduledTaskTier add 'snapshot' to the Skipper+ branch.
Backend test assertions are inverted for the now-Community endpoints
and a positive Skipper-snapshot-task test is added.
Documentation across features/, api-reference/, and operations/ is
updated to reflect the new tier mapping.
118 lines
6.9 KiB
Plaintext
118 lines
6.9 KiB
Plaintext
---
|
|
title: Remote Updates
|
|
description: Check for outdated nodes and trigger over-the-air Sencho updates from the Fleet View.
|
|
---
|
|
|
|
Sencho can update remote nodes directly from the dashboard. When a node is running an older version than the latest available release, a one-click update pulls the latest image and recreates the container automatically. This includes the local (gateway) node itself.
|
|
|
|
<Note>
|
|
Per-node remote updates and the Check Updates view are available on every tier (admin role required). The bulk **Update All** action is a Skipper or Admiral feature.
|
|
</Note>
|
|
|
|
## Prerequisites
|
|
|
|
Remote updates work when each node meets these conditions:
|
|
|
|
- Deployed via **Docker Compose** (the recommended method)
|
|
- The Docker socket (`/var/run/docker.sock`) is mounted into the container
|
|
- Running a Sencho version that supports the `self-update` [capability](/features/node-compatibility)
|
|
|
|
Nodes deployed with `docker run` or orchestrators like Kubernetes do not support self-update. These nodes show an error message when you attempt to update them.
|
|
|
|
## Checking for updates
|
|
|
|
Open the **Fleet** tab and click **Check Updates** in the header. This opens the **Node Updates** dialog, which lists every node with its current version and update status.
|
|
|
|
<Frame>
|
|
<img src="/images/fleet-view/fleet-node-updates.png" alt="Node Updates dialog showing update status for each node" />
|
|
</Frame>
|
|
|
|
The dialog includes:
|
|
|
|
- **Summary cards** at the top showing counts of nodes that are Up to date, have updates Available, are currently Updating, or have Failed
|
|
- **Latest version** label showing the newest available Sencho release
|
|
- **Filter** search box to find specific nodes by name or type
|
|
- **Node table** with columns for name, type, current version, latest version, and status
|
|
|
|
Each node's status column shows one of:
|
|
|
|
| Status | Meaning |
|
|
|--------|---------|
|
|
| **Up to date** badge | Node is running the latest available version |
|
|
| **Update** button | A newer version is available; click to update |
|
|
| **Updating** badge | The node is pulling the new image and restarting |
|
|
| **Updated** badge | The node came back online with the new version |
|
|
| **Timed out** badge | The node did not come back within 5 minutes |
|
|
| **Failed** badge | The update was rejected or the image pull failed on the remote host |
|
|
|
|
Nodes that are too old to report their version show "unknown" in the current version column. These nodes are treated as outdated.
|
|
|
|
### Updating state
|
|
|
|
When an update is in progress, the dialog shows a spinning "Updating" badge and the summary card count changes in real time. The Fleet View polls every 5 seconds while an update is active.
|
|
|
|
<Frame>
|
|
<img src="/images/fleet-view/fleet-node-updating.png" alt="Node Updates dialog showing a node in the updating state" />
|
|
</Frame>
|
|
|
|
## Updating a single node
|
|
|
|
You can trigger an update in two ways:
|
|
|
|
- Click the **Update** button next to a node in the Node Updates dialog
|
|
- Click the **Update to vX.Y.Z** button directly on a node card in Fleet View
|
|
|
|
For remote nodes, the update happens in the background. The Fleet View automatically polls at a faster rate (every 5 seconds) while an update is in progress, so you can watch the status change in near real-time.
|
|
|
|
## Updating all nodes
|
|
|
|
Click **Update All (N)** in the footer of the Node Updates dialog to trigger updates on all outdated remote nodes simultaneously. The local node is excluded from bulk updates to avoid losing dashboard connectivity. Nodes that previously failed or timed out are automatically retried in a bulk update.
|
|
|
|
## Local node updates
|
|
|
|
When you update the local (gateway) node:
|
|
|
|
1. A confirmation dialog appears explaining that the dashboard will briefly disconnect.
|
|
2. After confirming, the server pulls the latest image and restarts.
|
|
3. A reconnecting overlay appears and polls the server every few seconds. It stays visible for the entire pull and restart cycle, even if the API briefly responds in between, so the page does not reload until the new container has actually booted.
|
|
4. Once the new container reports a fresh boot timestamp, the page automatically reloads with the new version.
|
|
|
|
If the new container does not come up within 5 minutes, a timeout message appears with a manual reload option. If the gateway can detect that the update did not complete (for example, the image pull failed or the restart helper container could not spawn), the local node card surfaces a "Failed" badge with the underlying error within about 3 minutes instead of waiting for the full timeout.
|
|
|
|
<Note>
|
|
The self-update helper container inherits all bind mounts from the main Sencho container. If your `docker-compose.yml` references `env_file`, `configs`, or `secrets` outside the compose working directory, those paths must be mounted into the Sencho container using the same host and container path (1:1 rule). See [Troubleshooting](/operations/troubleshooting#local-self-update-fails-with-env-file-not-found) if you encounter "env file not found" errors during a local update.
|
|
</Note>
|
|
|
|
## What happens during an update
|
|
|
|
When an update is triggered on a node, Sencho:
|
|
|
|
1. Pulls the latest `saelix/sencho` image using Docker Compose
|
|
2. Recreates the container with the new image
|
|
3. The node goes briefly offline during the restart
|
|
|
|
The gateway monitors the remote node until it comes back online, then marks it as **Updated**. Completion is detected by three signals: a version change, a change in the node's process start time, or detecting that the node went briefly offline and came back (indicating a container restart). The "Updated" badge clears automatically after about 60 seconds and the node returns to "Up to date" status.
|
|
|
|
If the node is still reachable and unchanged after about 90 seconds, the gateway marks the update as **Failed**. This usually means the image pull failed on the remote host. Check the Docker logs on the remote node for details.
|
|
|
|
## Handling failures
|
|
|
|
If an update times out or fails, the badge shows **Timed out** or **Failed** with two action buttons:
|
|
|
|
- **Retry** (circular arrow icon) clears the failed state and re-triggers the update
|
|
- **Dismiss** (X icon) clears the failed state without retrying, returning the node to "Update available"
|
|
|
|
Hovering over a failed or timed-out badge reveals the error message with details about what went wrong.
|
|
|
|
<Frame>
|
|
<img src="/images/fleet-view/fleet-node-failed.png" alt="Node Updates dialog showing a failed node with retry and dismiss buttons" />
|
|
</Frame>
|
|
|
|
You can also click **Recheck** in the dialog footer to clear all failed and timed-out states at once, refresh the cached latest version from GitHub, and fetch fresh version information from every node.
|
|
|
|
<Note>
|
|
Update tracking is stored in memory on the gateway. Restarting the gateway clears all update states, so any stuck "Timed out" or "Failed" badges will resolve on their own after a restart.
|
|
</Note>
|
|
|
|
If you run into issues with remote updates, see the [Troubleshooting](/operations/troubleshooting#remote-update-button-does-not-appear) page.
|