On this page

Upgrade#

How#

Read the upgrade notes of every release between yours and the target.
Back up (backup-and-restore.md): at least the data key and the session key, and a snapshot of the two volumes if the notes say a table is rebuilt.
Upgrade with the values you installed with:
sh
```
helm upgrade hyvop oci://ghcr.io/hyvop-inc/charts/hyvop --version 0.9.0 -n hyvop -f my-values.yaml
```
While the 0.9.0 beta packages are private, log helm in first (helm registry login ghcr.io, see "Private packages" in install.md) and keep global.imagePullSecrets in the values file.

Keep your values in a file and pass it each time. --reuse-values keeps the values of the last install but not the defaults a newer chart adds; use it only for one-off changes on the same chart version.
Watch the pods: kubectl get pods -n hyvop. Core runs the changes to its schema and tables at its first start.
Sign in and read the ingestion card on Integrations.

The chart's version and the product's version are one number, and the chart runs the images built from the same tag. Core, the UI and the ingestors must all be of the release: do not mix an older ingestor image with a newer core. While the pods are being replaced a collection that falls due fails once and runs again at its next schedule, so do not upgrade on the hour.

A tool that renders the chart without reaching the cluster (Argo CD, helm template) cannot see what a Secret holds and would make new passwords and keys at every render. With such a tool, give the values or name an existingSecret for each concern, and give internalTls.existingSecret.

Detectors come with the release#

An install installs and runs the catalogue shipped with its release; upgrading brings the catalogue of the new release. When the registry publishes a higher version of a detector your organisation has installed, an administrator is offered the update and can apply it (Detection > Installed). Nothing is applied automatically, and a published rule is applied only if it passes the same checks as one that ships with the release. An install with no internet access is offered no update and loses nothing.

Roll back#

helm rollback hyvop <revision> -n hyvop restores the previous chart and, since the images follow the chart version, the previous images. It does not undo changes made to the stores' data: a table rebuilt by the newer core stays rebuilt. Take the backup first.

What the first release changes#

These are the notes for an install moving to the first release from an older chart. A new install needs none of this.

Check before you upgrade

Limits of the edition are enforced. Metrics are kept 30 days (they were 90). A scan lists at most 1,000 resources across all services and regions. Three active policies: those already active stay, a fourth cannot be switched on. The edition comes from a verified licence key; without one the install is the Community Edition. See editions.md.
Passwords. The chart no longer ships default passwords. An install made by an older chart keeps the passwords its stores were set up with. Set your own (postgres.db.password, clickhouse.password, or an existingSecret per concern) and change them in the stores.
No model key in the chart. The default of core.env.OPENAI_API_KEY is empty. An install that named a provider and relied on the old default must give a key of its own, or the upgrade stops with a message saying so.
Volumes. Every pod runs as its image's own non-root user. A volume created under root must be handed to that user: fsGroup does it where the volume driver honours it, otherwise chown once (PostgreSQL 70, ClickHouse 101).
Values are checked. A misspelled or wrongly typed value fails the upgrade with its path.
Secrets at rest. The chart makes a data key at this upgrade and keeps it in hyvop-core-secrets (data-key); at its next start core encrypts the secrets the database holds and turns session and link tokens into hashes. Keep a copy of the key with your backups. A Secret of your own (core.existingSecret) must gain data-key of 32 characters or more before the upgrade. An invitation link is shown once; send the invitation again for a new one.

Tables that are rebuilt (back up first)

Inventory. At its first start core makes the inventory table anew, carries the latest row of every resource over and keeps the old table, which can be dropped once you have checked. A resource deleted in the cloud then leaves the current inventory after the next complete scan and its findings close. "Stopped for N days" and "unattached for N days" count from when the state was first seen, so those two rules find nothing in their first days.
Prices. ClickHouse no longer fetches the AWS price lists; the ingestor does. Ask for a pricing collection after the upgrade. An install without internet access gives the ingestor a bundle of lists on disk (ingestors.aws.env.PRICING_SOURCE_DIR).
Cost figures change and are right. Cost was under-reported. The current billing period and the two before it are read again in full at the next billing collection, and their totals rise. Older months keep the figures they had.
Findings that rest on metrics change. Idle, over-provisioned and unused rules wait until a resource has 7 or 28 days of history, and read percentiles over thirty days.

Behaviour changes

First sign-in. There is no default login; the first person to open the UI creates the administrator (optionally behind core.setupCode).
AI is off until core.env.AI_PROVIDER names a provider (models.md). AI_PERSONAL_DATA is stand-ins.
Git servers on a private network. Core calls a Git server only at a public HTTPS address. Name an internal host in core.env.OUTBOUND_ALLOWED_HOSTS (comma-separated, *. for a domain).
Browser-side security. Only the install's own address may call the API from a browser with the session cookie; name any other origin exactly in core.env.CORS_ALLOWED_ORIGINS.
Ingestion runs on core's schedules (core.env.JOBS_INGESTION_*_CRON). Azure and GCP ingestors exist and are off until ingestors.azure.enabled or ingestors.gcp.enabled; one cloud account at a time in the Community Edition.
AWS with a role, and no stored key. ingestors.aws.serviceAccount.annotations and core.serviceAccount.annotations give the ingestor and core an identity (connect-aws.md).
HTTPS at the ingress is one setting (ingress.https). TLS between core and the ingestors is always on.
Sign-in through an identity provider works with core.env.AUTH_MODE: OIDC (install.md); single sign-on is an Enterprise feature.