Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.

Software Update

The Software Update tab lets an administrator upgrade the console — replace the running application container without touching the host directly. The console upgrade is a Docker image bundle named cybervault-upgrade-*.tar, uploaded on this tab.

This tab upgrades the console only. Copy agents and vault agents are upgraded separately: the agent JAR is uploaded and the copy agent upgrade started from Cyber Vault > Agent Fleet Management, and vault agents upgrade from Vault Operations. Each agent then upgrades itself (it pulls the new JAR on its next heartbeat; a copy agent waits while copy jobs are running).

A Quantum Trust Software Delivery card appears at the top of this tab. See the Quantum Trust Signed Delivery section below.

Quantum Trust Signed Delivery​

The Quantum Trust Software Delivery card lets you install a Superna-authenticated console upgrade package (.qtspkg) instead of a raw Docker image tar. QTS packages are cryptographically signed by Superna using ML-DSA-87 (NIST FIPS 204, a post-quantum digital signature algorithm). The console verifies the signature before allowing installation.

Both delivery paths are valid. Each path runs different checks:

PathWhat is checked
.qtspkg packageML-DSA-87 signature plus payload integrity
Plain Docker image tar, plain agent JAR uploadChecksum only. Signatures are not checked

Superna recommends the .qtspkg path.

How QTS upload works​

  1. Drag and drop a .qtspkg file onto the card, or click to browse
  2. The console uploads the package and verifies its signature, target component, payload integrity and version before allowing installation.
  3. The result badge appears immediately:
    • Quantum Trust Signed (green) — signature valid, safe to install
    • Quantum Trust Signed + Customer Encrypted (green + teal badge) — signed and encrypted for this installation; all validation checks passed
    • Signature Invalid (red) — the file was not signed by Superna or has been modified
    • Unknown Signing Key (red) — the signing key is not trusted by this console; update the console first
    • Wrong Component (amber) — this package is for a different component; use the correct upload location
    • Rollback Blocked (amber) — the version is below the minimum allowed by the signing manifest
    • Invalid Package (red) — the file is not a valid .qtspkg or required entries are missing
    • Wrong Installation (red) — this customer-encrypted package was produced for a different console installation. Your System Public Key fingerprint does not match the fingerprint embedded in the package. Go to Setup & Settings > Security > System Public Key, copy your fingerprint, and contact Superna to request a re-encrypted delivery.
    • Decapsulation Failed (red) — the package's delivery key could not be processed. Re-download the package from Superna.
    • Delivery Key Unavailable (amber) — this console could not load its own software delivery key, so a customer-encrypted package cannot be opened. The package itself may be fine. The message shows the reason; see Setup & Settings > Security > System Public Key for what to do.
    • Decryption Failed (red) — the encrypted payload may be corrupt or does not match this installation. Re-download the package from Superna.
  4. If validation passes, click Install Build N to confirm the installation
  5. A service restart is required to apply the update

Customer Encrypted (QCE) packages​

When Superna produces a QCE package for your installation, the payload is encrypted with AES-256-GCM using a key that only your console can recover. The delivery key is encapsulated with your installation's ML-KEM-1024 public key — a post-quantum key encapsulation mechanism (NIST FIPS 203). This means the package can only be decrypted by the specific console it was built for.

The console additionally checks that the package was built for this installation and decrypts it. Any corruption is detected.

If you receive a Wrong Installation error, the package was built for a different console. Go to Setup & Settings > Security, locate the System Public Key (ML-KEM-1024) section, and copy your key fingerprint. Send it to Superna when requesting a new package.

Standard upload​

The plain Docker image tar upload below the QTS card is always available. The QTS and standard paths are independent — you can use either. The standard path does not check a signature, only a checksum. Console image uploads and agent JAR uploads are not signature-checked.

How upgrades work​

The console runs as a container on the appliance. An upgrade replaces it with the new version and restarts it. Because a running application can't replace itself, a service on the appliance performs the swap when you click Apply Upgrade. It then checks that the new version is healthy and rolls back automatically if it isn't (see Automatic rollback below).

Staged upgrade​

A build can also be staged on the appliance outside this tab, for example from the appliance shell or by support. The console then shows a green Build N ready to apply card with:

  • Build number and Image tag of the staged build
  • MD5 checksum — compare it to the checksum published with the build to confirm the file transferred without corruption
  • Size and Staged (when the file was placed)

Clear staged image removes the staged build without applying it, for example after uploading the wrong file. If the staged build is the one already running, the card says Build N is already running — no upgrade needed and offers only Clear staged image.

Manual upload​

If you have a Docker image tar file on your machine (created with docker save), you can upload it directly:

  1. Drag and drop the .tar file onto the upload area, or click to open a file picker
  2. Click Upload — the button disables itself for the duration of the upload, so it can't be triggered a second time while one is already running
  3. A progress bar shows upload progress; for large files (typically 1–2 GB) this may take several minutes depending on your network connection. Cancel stops an upload in progress and discards it
  4. After upload completes, the console validates the file, computes checksums, and moves to the Ready state.

If an upload stalls for 5 minutes, the console resets to Idle so you can retry.

Apply Upgrade confirmation​

When you click Apply Upgrade, a confirmation dialog shows the build number and image tag you are about to install. After you confirm, the GUI shows an amber Replacing container banner, then Waiting for restart while the console restarts. When the new version responds, the page reloads automatically.

Total downtime is approximately 1–2 minutes. Plan upgrades during a maintenance window if the system is in active use.

Automatic rollback​

After restarting on the new version, the appliance checks that it is healthy. If it isn't, the previous version is restored automatically and the console shows a red Upgrade failed banner with the reason. Dismiss clears the failure, removes the staged build and resets to the Idle state.

If an uploaded file isn't a valid image bundle, it is refused before anything changes, and the running version stays in place. If both the new version and the rollback fail, the GUI shows an Upgrade and rollback both failed banner with instructions to connect directly to the host.

Operating system patching​

In the Dell build, a weekly job patches the console operating system with zypper patch. It is on by default and never reboots the appliance. It writes to /var/log/cybervault-os-patch.log. There is no setting for it on this page and no alarm if it fails. If the console cannot reach the openSUSE mirrors (flow #15 in the firewall matrix), it stays unpatched without any notice, so check the log from time to time.

MD5 verification​

The MD5 checksum shown on the Ready card is computed during upload. To verify the image was not corrupted in transit:

  1. On the machine where you downloaded the file, run: md5sum /path/to/cybervault-upgrade-*.tar
  2. Compare the output to the MD5 shown in the GUI

If the values differ, dismiss the staged image and re-upload. Do not apply an image with a mismatched checksum.

State reference​

StateMeaning
IdleNo staged image; only the upload section is shown
UploadingImage tar is being streamed to the host; progress bar is visible
ValidatingUpload complete; tar header and minimum-size checks running
ReadyValidated image is staged; Apply Upgrade is available
UpgradingTrigger written; container replacement in progress
FailedUpgrade failed; the previous version is running (rolled back automatically, or never replaced when the upload was refused)
Rollback FailedNeither the new nor the previous version became healthy; manual intervention required