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
- 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.
- Snapshot the stateEnough to put the server back exactly as it was.
- Swap the releaseThe new release is unpacked beside the old one and the
bin/klyrnsymlink moves. The previous release stays on disk. - 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.
- CheckServices active, the panel answering, the sites answering.
- 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.
| Channel | Required |
|---|---|
dev | The release gate: build, vet, tests, formatting, both front ends, the website verifier and a secret scan. |
beta | All 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. |
stable | All 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:
| What was served | What KLYRN said |
|---|---|
| No manifest | manifest: HTTP 404 |
| A manifest that is not JSON | manifest signature is malformed |
| A valid manifest, signed with the wrong key | manifest signature does not verify: refusing this release |
| A correctly signed manifest, artefact missing | download: HTTP 404 |
| A correctly signed manifest, different bytes | downloaded binary does not match the manifest checksum; refusing to install it |
| A binary that reports a different version | downloaded binary reports version "…", manifest says "…" |
| A release needing a newer server | this 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.