Updates

Which channel you are on, and what beta means

klyrn update status                 # channel, current version, last check
klyrn update channel beta           # move this server to a channel

There are three channels. A server reads only the manifest for the one it follows, so a beta build cannot reach a stable server by accident. The public install command installs stable. KLYRN_CHANNEL=beta installs the newest pre-release, and says so before it downloads anything.

Beta means tested and not finished. Every release on this channel has passed the gate below, with no known critical defect. The gate includes a clean upgrade through the updater on a real server and a reboot afterwards. A release on stable has passed the stricter gate in the same table, and a server on beta is offered each one like any other update.

See what KLYRN does not do. The changelog lists what each release fixed.

Updating by hand

klyrn update --check                    # is there one, and what is in it
klyrn update                            # apply it, with a confirmation
klyrn update --yes                      # without one
klyrn update --channel beta
klyrn update --version 0.1.81-dev
klyrn update status

Or from the panel: System updates, then Check now, then Update now. Both take the same path.

What an update does

1. Fetch and verifyThe release manifest is signed with ed25519, and the public key is built into the binary you are already running. Every artefact is checked against its SHA-256. A mismatch stops here, before anything on the server changes.
2. Snapshot the stateEnough to put the server back exactly as it was.
3. Swap the releaseThe new release is unpacked beside the old one and the bin/klyrn symlink moves. The previous release stays on disk.
4. Re-apply the templatesConfiguration KLYRN owns is regenerated from the new version's templates, so a fix to an nginx or FPM template reaches existing sites.
5. CheckServices active, the panel answering, the sites answering.
6. Roll back if a check failsAutomatically. The symlink moves back, the state snapshot is restored, and the update is reported as failed.

Automatic updates

klyrn update auto on
klyrn update auto off
klyrn update window 03:00-05:00     # server local time
klyrn update channel stable

With automatic updates on, KLYRN applies an available release only inside the window you set. The outcome is emailed if you have configured the SMTP relay. It is always in klyrn update status and the job list.

Updating every server from one place

my.klyrn.com shows every server your licence keys have activated, which release each one is running, and which are behind. It moves them with one click, without a terminal.

Nothing on that platform reaches into your servers. There is no stored root password, no SSH key, no open port and no remote command. Each server calls out, reads the version it should be running, and installs that release itself. It verifies the signature against a key built into its own binary, which the platform has never held. The strongest instruction the platform can express is a version number.

• Update one, or select several, or all of them.
• One at a time by default. A rollout has a concurrency and a failure budget. It stops itself when the budget is spent.
• Canary first. Nominate a server to take a release before the others do.
• The same health checks and the same rollback as an update run by hand, because it is the same updater doing the work.
• A server that is out of contact is skipped, and updates when it comes back.

A server has to agree. Fleet updates apply only to a server with fleet.enabled on, which is separate from update.auto. A machine can accept updates from its own schedule and still refuse to be driven from the platform.

What an update refuses

Before a single file is replaced, KLYRN checks four things. The first is the manifest's signature against the public key built into the running binary. The others are the artefact's SHA-256, the version the downloaded binary reports about itself, and whether this server is new enough to upgrade at all. A build with no key embedded refuses every update.

Each refusal was tested by serving a server a deliberately broken release. Afterwards the server was still running the version it started on:

After the switch, the post-checks run. If core, the panel, nginx or health does not come back, the previous release is restored from disk by moving the symlink back. The state snapshot taken before the migrations undoes them.

Operating-system updates

KLYRN updates KLYRN. It does not manage Ubuntu's own packages. The installer neither enables unattended-upgrades nor turns it off.

Keep the OS current the way you would on any server. KLYRN owns nginx.conf, the FPM pools and the MariaDB tuning file. A package upgrade that replaces one of those is reverted the next time templates are applied. KLYRN touches nothing else on the machine.

After a reboot

Everything comes back on its own. Both KLYRN units, nginx, PHP-FPM, MariaDB and every Node application unit are enabled, and cron entries are reconciled at start-up. Jobs that were running when the machine went down are marked failed with "interrupted: klyrn-core restarted". Resumable jobs are a later milestone.

Verified after a real reboot of the test server: uptime one minute, five services active, panel and site both answering 200.