All documentation
  1. Home
  2. Docs
  3. Updates

Updates

An update that cannot roll itself back is an outage waiting for a bad release. KLYRN keeps the previous release on disk and swaps a symlink, so going back is the same operation as going forward.

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

Three channels, and a server only ever reads the manifest for the one it follows, so a beta build cannot reach a stable server by accident. The public install command installs beta, and says so before it downloads anything.

Beta means tested and not finished. Every release on this channel has passed the gate below, including a clean upgrade through the updater on a real server and a reboot afterwards, with no known critical defect. It does not mean the product is done. In practice:

  • Use a fresh server, or one whose contents you can afford to lose.
  • Take the updates. Fixes land here; two of the betas after the first fixed defects that took real sites down.
  • Keep your own copy of anything irreplaceable. KLYRN’s backups are verified and restore-tested, and a beta is still not the place to hold the only copy of something.

There is no stable release yet. What KLYRN does not do is the rest of the picture, and the changelog lists what each beta 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 → Check now → 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 rather than as done.

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 inside the window you set and nowhere else. The outcome is reported by email if you have configured the SMTP relay, and it is always in klyrn update status and the job list.

Three channels, and a server only ever sees the one it follows. A server on stable reads only the stable manifest, so a beta build cannot reach it by accident.

What a release must pass before it is published to a channel
ChannelRequired
devThe release gate: build, vet, tests, formatting, both front ends, the website verifier and a secret scan.
betaAll of that with the browser audits, plus a clean upgrade through the updater, a reboot afterwards, the main hosting workflows on a real server, and no known critical defect.
stableAll of that, plus a clean install on a fresh machine, an upgrade from the previous stable, a rollback performed by the update system, the whole customer journey through public paths, browser QA on every route, the security suites, backup and restore, a migration, and a reboot with health green afterwards.

Updating every server from one place

One server at a time is fine until there are twenty. my.klyrn.com shows every server your licence keys have activated, which release each one is running, and which are behind. It moves them, one click, without anybody opening 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, verifying 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 rather than working through the rest of the fleet.
  • 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 only apply 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 manifest's signature against the public key built into the running binary, 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 rather than accepting an unsigned one.

Each of these was tested by serving a server a deliberately broken release and checking it was still running the version it started on afterwards:

Refusals, as the server reports them
What was servedWhat KLYRN said
No manifestmanifest: HTTP 404
A manifest that is not JSONmanifest signature is malformed
A valid manifest, signed with the wrong keymanifest signature does not verify: refusing this release
A correctly signed manifest, artefact missingdownload: HTTP 404
A correctly signed manifest, different bytesdownloaded binary does not match the manifest checksum; refusing to install it
A binary that reports a different versiondownloaded binary reports version "…", manifest says "…"
A release needing a newer serverthis release requires at least …; you run …. Update to an intermediate release first

After the switch, the post-checks run. If core, the panel, nginx or health does not come back, the previous release is restored (it is still on disk, so going back is the same symlink move as going forward), and the state snapshot taken before the migrations is there to undo them.

Operating-system updates

KLYRN updates KLYRN. It does not manage Ubuntu's own packages, and it leaves unattended-upgrades exactly as it found it: the installer does not enable it and does not turn it off.

Keep the OS current the way you would on any server. KLYRN takes ownership of nginx.conf, the FPM pools and the MariaDB tuning file, so a package upgrade that replaces one of those is reverted the next time templates are applied; nothing else on the machine is KLYRN's business.

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, and being honest about interruption is the behaviour today.

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