Operations

Updates And Version Management

How Sendense components receive new versions, how update readiness is checked, and how update status is tracked in the GUI.

ReadyCurrentupdatesversionslifecycle

Overview

Sendense updates are promoted from the GUI. Customer updates are designed to be straightforward: administrators promote the latest version and the update workflow runs automatically.

Update flow

From the GUI

Promote Update

An administrator promotes the target version. Available versions and current versions are visible per component.

Live pre-update check

Safety Gate

Sendense checks for genuinely running operations. Unsafe-to-interrupt work blocks the update; re-runnable work warns and can be drained with update-when-ready.

Automated workflow

Apply With Progress

The update workflow runs automatically with tracked progress and final status.

Operator review

Health After Update

Components report their new version and health. Failed or rolled-back updates need operator review.

Update Status And Control

Sendense tracks component versions and exposes update status through the GUI. Each component shows its current version and, where relevant, an available or target version.

Update runs move through queued, running, and completed states. Failed, rolled-back (where supported), and skipped outcomes are shown for review, and readiness gates run before an update executes.

Update controls in the SHA GUI are customer-operable, subject to RBAC, edition, readiness gates, and provider access controls. MSP-managed customers may delegate agreed update actions to the MSP through SCA, and CSPs decide whether tenants receive direct SHA update controls, API-driven controls, or provider-managed update workflows.

How Each Component Updates

SNA

Current and available SNA versions are visible per appliance. Updates can be started from the appliance view where permitted, with progress and the current step shown in the GUI. Review failure or rollback status before retrying.

snagent

Administrators set or clear a fleet target version in SHA. Host agents verify update material and self-update to the target on check-in when the host is reachable, so fleet updates follow check-in timing rather than completing instantly. An interrupted host-agent update rolls back rather than leaving the agent half-updated, and clearing the target disables self-update.

Sendense Controller

A customer administrator promotes the latest controller version in the GUI, and Sendense automatically updates eligible controllers. Updates wait for sync work to complete where needed, controllers in failover or commit states can be skipped, and rollout may proceed one controller at a time where enforced. Review sync and failover readiness after completion.

SHA

SHA maintenance may affect GUI access, scheduling, orchestration, and monitoring. Plan SHA updates in a maintenance window and review health after completion.

Update Safety

Sendense applies a pre-update safety gate before an update runs. The gate checks for operations that are genuinely running at that moment, using live runtime evidence rather than stale job records.

Operations that would be unsafe to interrupt block the update until they finish. Re-runnable work, such as an in-flight backup, replication sync, or restore, produces a warning instead — the operator can choose to update when ready, and the update starts once that work completes.

If an installation is interrupted mid-flight, rollback behavior is intended to protect the update process.

Lifecycle Management

SHA coordinates appliance and component lifecycle workflows exposed through the GUI, including supported SNA and snagent lifecycle operations where applicable.

What It Is Not

Version management is not repository retention.
Updating a component is not the same as reprovisioning it.
Clearing a target version does not remove already installed software.
A queued update does not mean the component is currently updating.