Get and update Heliast

This page says how Heliast software reaches you, how you check it, and how you apply and roll back an update, for each way your site can be connected. It also says plainly which parts exist today and which are still to come. Read it before you plan an installation or an upgrade.

What you receive

Heliast is delivered as files that you check and apply yourself. Nothing on the request path ever reads a delivery, and nothing is pushed to you.

What	What it is
Release bundle	The container images, the Helm chart and the Terraform modules for one platform version, with a software bill of materials, a vulnerability delta and release notes, signed by Heliast.
Advisory bundle	Data only, never code, images or weights: the watch on upstream model releases and licence changes, refreshed evidence data, and hardware-fit ranges.
Verdicts	Signed verdicts and attestations for admitted models.
Model weights	Not from Heliast. They come from each model's publisher and are checked against the digests Heliast pinned (see using an admitted model).
Licence file	A signed, time-bounded file you validate offline. An expired licence never stops inference.

How your site is connected

There are three modes. The same files arrive in each; only the route differs.

	Connected	Periodic	Severed
Link to Heliast	An outbound link your operator starts, left open	Opened by your operator when you choose, then closed	Never established
How a release reaches you	Downloaded over the link	Downloaded in order when the link is open	Downloaded on a separate machine, carried on removable media (a USB drive), and brought into your environment
What you do next	Check it, stage it, apply it	The same	The same

Severed operation is standard in every tier. Inference, policy, the ledger and evidence generation all run in full with the link never established.

What exists today

Be clear about this before you rely on a step.

Built and tested: the signed bundle format, and the tool that builds and checks one (offline-bundle), which works with no network. Checking model weights with model-pull. Checking a licence file with licence-validate.
Built, not yet run in a real estate: the nine-stage deployment pipeline, and loading Heliast's own images into a single node.
Not built yet: a public place to download from, a registry (Heliast does not run one for you), an update check, release notes in the bundle, loading a whole bundle's images into a multi-node cluster, and any import screen in the console. The console has no import or upload feature: a bundle is checked and applied with the tools on this page, not through the console.
Not yet available to a customer: a complete signed release bundle that carries all the images. Its checks are not yet all passing (see the status below).

Ask your Heliast contact where to download from and which key fingerprint to expect. Until a download location is published, deliveries are arranged with you directly.

Check a bundle (every mode)

The offline-bundle tool needs no network and no extra trust root. It checks a bundle in this order: the key matches the fingerprint you expect, the key is the right kind of key, the signature is valid, the manifest's content digest recomputes, every listed file exists inside the bundle with its listed digest and size, the bill of materials and vulnerability delta are present, and nothing unlisted was added.

offline-bundle verify \
  --bundle <the bundle: a directory, a .tar.gz file, or an https address> \
  --public-key <heliast-release-public-key.pem> \
  --expected-key-fingerprint <the 64 hex characters Heliast gave you>

Always give --expected-key-fingerprint. Without it, a release check trusts whatever public key you hand it, so it proves only that the bundle matches that key. An advisory bundle is refused without a fingerprint. Add --kind advisory for an advisory bundle, and --json for machine-readable output. A bundle that fails the check is not applied. Keys are purpose-bound: the key that signs advisories cannot verify a release.

The fingerprint must reach you by a route you trust, not inside the bundle. Heliast has not yet published a production signing key; do not accept a fingerprint from anyone but your Heliast contact.

To use the contents, unpack the archive yourself (tar -xzf <bundle>.tar.gz). The tool checks an archive and removes its temporary copy; it does not unpack for you.

Severed: carry it across

On a machine with access, download the bundle and its public key. Record the fingerprint you were given separately.
Copy them to removable media.
At your site, check the bundle from the media, offline:

`` offline-bundle verify --bundle /media/usb/<bundle>.tar.gz \ --public-key <key.pem> --expected-key-fingerprint <hex> ``

Unpack it, load the images, and apply the release as below.

Images

Heliast's own images are built to be reproducible and are pinned by digest, so the cluster runs exactly the bytes that were checked. There is no registry in the default design, so the images travel inside the bundle as files and are loaded into each node's container runtime.

One node: scripts/load-rig-images.sh loads the images from their archives and tags each one with its pinned digest, which a plain ctr images import does not do. Without the digest tag, a pod that names an image by digest fails to start with ImagePullBackOff even though the image is on the node. Use --dry-run first.
Several nodes: every node needs the same image records, or you run your own registry and load the images into it. This is not yet supported by a tool; ask your Heliast contact how to proceed.
Only Heliast's four first-party images (the audit service, the hook, the response service and the test sign-in service) are built this way today. Third-party images in the chart are pinned by digest, but their bytes are not yet in a bundle.

A severed site must also provide its own copy of K3s and the NVIDIA driver. The pipeline's installer fetches them from the internet, so it does not work offline as shipped.

Apply, stage and roll back

Stage first. Apply a release to a non-production environment before production. The pipeline's smoke-test and baseline stages run again there (deploying).
Apply. The platform stage runs helm upgrade --install with --atomic --wait, so a release that does not become ready is rolled back by Helm. This has not run in a real cluster.
Roll back software. Use helm rollback to the previous revision. Keeping the previous release's images on the node is your job: nothing keeps them for you.
Roll back policy. A policy rollback is a Git revert of your policy repository, and the pipeline's policy stage loads it. See policy and entitlement.
Weights. The weights volume keeps the current and two previous model versions when the runtime chart is enabled.
The ledger is never rolled back. Whether a database migration in a new release can be reversed is not yet stated; ask before you upgrade across a release that changes the ledger schema, and back up first (backup and restore).

Other updates

Advisory bundle: check it with --kind advisory and a fingerprint, as above. It holds data only (JSON files). Nothing in a running service reads it automatically; your team reads it and decides.
Model weights: model-pull pull -manifest <manifest.json> -source-dir <directory on your media> -dest <models directory> checks every file by digest and format before anything is placed, and -public-key requires the publisher's signature. -source-dir is the route for removable media; -source-url is for a connected site. A mismatch aborts the whole pull.
Licence: licence-validate -file <licence file> -warn-days 30 checks the file offline and says how long it has left. A renewed file reaches a severed site the same way as a bundle. How the running system picks up a new licence file is not yet documented; ask your Heliast contact.

What is not ready yet

These are the gaps today. Each is on the list for the first customer release.

A download location and its sign-in.
A published production signing key and fingerprint.
A complete signed release bundle with all images, a bill of materials, a vulnerability scan and release notes. The checks that produce one are not all passing yet.
A tool that loads a bundle's images into a multi-node cluster.
A platform version number and a release-notes format.
A statement about reversing database migrations.