> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kvelden.com/llms.txt
> Use this file to discover all available pages before exploring further.

# System upgrade

> How to upgrade the Kvelden Enclave appliance to a new release from the admin GUI — a signed, verified, self-healing update with automatic rollback. Standalone appliances update in place with a brief reboot; clusters roll one node at a time with zero downtime.

<Info>
  Upgrades are performed by the appliance **owner** from the admin GUI. Every
  update is **cryptographically signed by Kvelden and verified on the appliance
  before anything is installed** — nothing runs unless the signature and version
  checks pass. The appliance is **air-gap friendly**: you upload a bundle file,
  no internet access is required.
</Info>

## How Enclave upgrades work

Enclave ships each release as a single **signed update bundle**
(`enclave-update-<version>.tar.gz`) containing the new operating-system image and
the new application. You obtain the bundle from Kvelden, upload it in the admin
GUI, and the appliance does the rest.

Two design guarantees make this safe to run on a production system:

<CardGroup cols={2}>
  <Card title="A/B system slots" icon="layer-group">
    The appliance keeps **two operating-system slots** (A and B). An upgrade is
    written to the **inactive** slot and the appliance reboots into it. The
    previous slot is kept intact, so a failed upgrade can fall back instantly.
  </Card>

  <Card title="Verified, self-healing apply" icon="shield-check">
    After the reboot the appliance starts the new version and runs a **health
    gate**. If the new version is healthy it is committed; if not, the appliance
    **automatically rolls back** to the previous slot — the OS and application
    always move together, never split.
  </Card>
</CardGroup>

<Steps>
  <Step title="Verify">
    The bundle's signature, format, and version are checked on the appliance.
    A tampered, corrupt, or older-than-installed bundle is rejected before any
    change is made.
  </Step>

  <Step title="Snapshot">
    A safety database snapshot is taken automatically before the application is
    changed, so a rollback restores both the OS **and** the data.
  </Step>

  <Step title="Install to the inactive slot">
    The new OS image is written to the standby A/B slot. The running system is
    untouched until it reboots.
  </Step>

  <Step title="Reboot & activate">
    The appliance reboots into the new slot and applies the new application.
  </Step>

  <Step title="Health-gate & commit (or roll back)">
    The new version is health-checked. Healthy → committed. Unhealthy →
    automatic rollback to the previous slot with your data intact.
  </Step>
</Steps>

## Choose your path

<CardGroup cols={2}>
  <Card title="Standalone upgrade" icon="server" href="/deployment/appliance/upgrade/standalone">
    A single appliance. Updates **in place** with a brief reboot (a few minutes
    of downtime while the appliance restarts into the new version).
  </Card>

  <Card title="Cluster in-place upgrade" icon="layer-group" href="/deployment/appliance/upgrade/cluster">
    Two or more clustered appliances. Rolls **one node at a time, standbys first
    and the primary last — with zero user-visible downtime**.
  </Card>
</CardGroup>

## Before you upgrade (both paths)

<AccordionGroup>
  <Accordion title="Sign in as the owner">
    Software updates are owner-only and require an additional password
    confirmation (step-up) at the moment you apply. Sign in with the owner
    account before you begin.
  </Accordion>

  <Accordion title="Obtain the signed bundle from Kvelden">
    Download the release bundle (`enclave-update-<version>.tar.gz`) provided by
    your Kvelden account team. Keep it on the machine you'll use to access the
    admin GUI. No internet access is needed on the appliance.
  </Accordion>

  <Accordion title="Check free disk space">
    An upgrade needs working room for the bundle plus the new images. The GUI
    runs a **preflight** that checks this and refuses to start if space is
    short, so you'll never begin an upgrade that can't finish. If preflight
    flags disk space, free some (e.g. remove older uploaded bundles under
    **Software Update**) and re-run it.
  </Accordion>

  <Accordion title="Confirm the clock is sane">
    A correct clock is required for signature and TLS validation. Check
    **System → Diagnostics**; if time is off, set it under the appliance's
    time settings before upgrading.
  </Accordion>

  <Accordion title="Have a recent backup (recommended)">
    The upgrade takes its own automatic safety snapshot, but an independent,
    verified backup (**Admin → Backup & Restore**) is always good practice
    before a maintenance action. On a cluster, each node must have a backup key
    configured.
  </Accordion>
</AccordionGroup>

## What you don't have to do

<Check>No console, SSH, or command line — the entire upgrade is driven from the GUI.</Check>
<Check>No manual rollback scripting — rollback is automatic if the new version is unhealthy.</Check>
<Check>No internet on the appliance — updates are offline bundle uploads.</Check>
<Check>On a cluster, no per-node file copying — the bundle is distributed to peers automatically.</Check>