Skip to main content

Update an on-premise platform

An on-premise deployment is upgraded by running the installer, either the release archive Clika sends you or the one the installer downloads from the update channel. Nothing is applied on its own: the platform tells you that a release exists, and you run the command on the platform node. This guide assumes a platform installed by clika-install, the installer inside the release archive, and covers the notice, the upgrade and the way back.

Learn that a release exists​

A deployment whose license reports to the CLIKA License Portal asks the Portal's update channel once a day which release is published for it. When a newer version exists, the administration dashboard (Admin) shows one banner with the version, the date it was published, a link to its release notes and the exact command to run on the platform node. Dismiss for this version hides the banner in your browser until the next version is published. The banner applies nothing.

An air-gapped deployment never asks the Portal. Its dashboard shows a note that updates are delivered as archives, and a release reaches it as a file, as below.

The same check runs from the node, with the installer you installed with:

sudo ./clika-platform-<version>-install.run --check-updates

It prints the installed version, the newest release on the channel, the one it would apply next (one release line at a time), whether that release is signed by a key the installer trusts, whether its archive is already downloaded, which archive it would fetch, and the command to apply it. Nothing is downloaded or changed.

Apply a release​

From the channel:

sudo ./clika-platform-<version>-install.run --upgrade

The installer downloads the release into /var/lib/clika-platform/downloads (the last two releases are kept there), checks Clika's signature and the archive's checksum before anything of it runs, shows what the upgrade does and how long it takes, asks once, and then runs the downloaded installer. A download interrupted by a dropped connection resumes where it stopped when you run the command again.

From a file, copy the newer archive to the platform node and run it as you ran the first one:

sudo ./clika-platform-<newer-version>-install.run

Either way the installer recognises the existing installation, keeps every answer you gave, asks once for the license passphrase, shows what changes before it proceeds, backs up the database (below), replaces the platform's container images and waits for them to roll out. Your data, your license, your certificates and your administrator account are kept, and registered devices stay connected. The web application is unavailable for about a minute while the services restart. Afterwards, --verify re-checks the installation without changing it.

Which archive applies​

A release is published as the full archive, clika-platform-<version>-install.run. When the ClikaRT engine and the benchmark catalogue did not change since the previous release, a platform-only patch, clika-platform-<version>-patch.run, is published beside it with the same installer, images and agent payload and without the benchmark catalogue. --check-updates names the one --upgrade will fetch, the smallest that applies to your node. A patch carried by hand refuses a fresh install and a node whose catalogue is not the one it expects, naming the full archive to apply instead. Both archives are signed the same way.

Versions the installer refuses​

An archive older than the installed version is refused; going back is the rollback below, not an install. An archive more than one release line ahead of the installed version is refused as well, naming the version to install first. --upgrade steps one release line at a time and says so when the channel's newest release lies beyond the next step.

The release notes​

Every archive carries its release notes as RELEASE_NOTES.md, the text the dashboard banner and --check-updates link, so they can be read on the node without a browser. The notes say what changed, what the upgrade does, how long it takes and what is visible while it runs.

The benchmark catalogue​

Before it applies the catalogue, the installer checks the archive's benchmark payload against the platform's store. A missing required artifact stops the catalogue step and is named in the summary; the platform itself is already upgraded at that point, and re-running the installer once the artifact is in place completes the catalogue. A missing optional artifact is reported together with the benchmark definitions it affects, and the catalogue is applied without them.

Return to the previous version​

Before the upgrade writes anything, the installer backs the database up under /var/lib/clika-platform/backups/<date-time>-<version replaced>/ on the platform node, together with a record of the object-store volume and of the installer state as it was. The last three backups are kept; --backup-dir and --backup-keep change the directory and the count. The upgrade refuses to start when the disk cannot hold the backup, naming the free space, the database size and the flag. Artifacts stay on their own volume across upgrades and rollbacks and are not part of the backup. The closing lines of an upgrade name the backup and the exact rollback command.

To return to the version the upgrade replaced, run the same installer file with --rollback:

sudo ./clika-platform-<newer-version>-install.run --rollback

It brings back the previous version's images (kept on the node since the upgrade), shows what it will change and asks again before it touches the database. Restoring the database from the backup discards everything written since the upgrade, so that question takes a typed answer, and --restore-database answers it for an unattended run. When the upgrade changed the database schema the restore is required; otherwise the database is kept by default. --bundle <the previous archive> supplies the previous images when the node dropped them. Secrets and certificates are untouched.

Where the installed version shows​

The upgrade banner names the installed version beside the one it offers, and the platform's health endpoints (/api/health, /api/ready and /api/livez) carry it as version, so monitoring can tell which release a deployment runs without reading its image tag.