KLYRN
Install Free

Changelog

What shipped, and when.

KLYRN has not cut a stable release yet. The current build is 0.3.5‑beta.1, published 2026‑09‑11 on the beta channel, and it is what the public install command installs. An item appears here only once it has been made to work on a real server, not when the code compiled.

Where these entries come from. Every 0.3.x build on this page has a version and a date because it was published: the numbers and the dates are read back out of the signed release index the panel itself reads, and the text out of the release notes that shipped inside each manifest. The older entries predate that: their versions come from the milestone headings in docs/STATUS.md, the "shipped" column in docs/COMPETITIVE-GAP.md and docs/RECOVERY-MANIFEST.md, and their dates are the date of the git commit that introduced the code, which is why they cluster. Where a version number was never recorded, this page says so instead of inventing one. No release date has been announced for any of these builds.

Recent

Also in the 0.3.0 betas.

These landed between 0.1.81‑dev and the first beta, and are part of it. They had no version number of their own, so they are listed by the date of the commit that introduced them.

  1. not recorded2026-09-06

    Logs centre, WordPress clone and policies, .htaccess analyser

    • A per-site logs centre that lists the sources a site has and follows them incrementally by cursor. Server-wide sources are administrator-only, because KLYRN's journal carries every site's traffic.
    • klyrn wp clone: an independent copy with its own database, its own database user and password, and its own certificate.
    • klyrn wp health: ten deterministic WordPress signals, and four named hardening actions.
    • klyrn wp policy: per-site update policy for core, plugins and themes, running once a day between 02:00 and 06:00, backing up first and verifying the site answers afterwards.
    • An .htaccess analyser and a migration verification report that compares the new site against the source before DNS changes.
    • A ninth API token scope, migrate.
  2. not recorded2026-09-06

    Account deletion and ownership transfer

    • Deleting an account: a preview counted from the database, the account name typed to confirm, and the off-site copies kept by default.
    • --backup-first backs every site up and stops if a backup fails.
    • Transferring an account moves who manages it and nothing else. No file moves, no path changes.
  3. not recorded2026-09-06

    Signed outbound webhooks

    • Thirteen events, delivered over HTTPS only, signed t=<unix>,v1=<hex> with HMAC-SHA256 over <t>.<body>.
    • Six attempts with a widening backoff; private, loopback and metadata addresses refused, and the resolved address checked again at connect time.
    • No customer content is ever in a payload.

    The signature scheme

  4. not recorded2026-09-06

    API token scopes

    • Tokens can be narrowed to a set of scopes, checked in the privileged core before the role check.
    • A scope never widens what its owner may do; a token with no scopes keeps the owner's full authority, which is what existing tokens had.
  5. not recorded2026-09-06

    Deterministic per-site diagnostics

    • klyrn site diagnose runs every probe in the order a request travels and names the cause, not just the symptom.
    • Six named repairs and no seventh: a repair has no field that could carry a command, a path or an argument.
    • The HTTP probe stays quiet when something upstream already explained the failure.

    Troubleshooting

Recorded builds

Builds whose version was written down.

  1. 0.3.5-beta.12026-09-11

    A file editor that corrupted what it saved, and a save that discarded somebody else’s work

    • The file editor could corrupt a file it saved. KLYRN decided whether a file was text by reading its first 8 KB. A file that begins with text and turns binary later (a compiled asset, a font, a dump with a header) passed, was opened in the editor, and came back with every byte it could not represent replaced. Saving wrote that over the original, silently. Measured on a real server: a 9,649-byte file diverged at offset 9,644. If you have edited a file with binary content in it, compare it with a backup.
    • Two people in one file: the second save overwrote the first, and nobody was told. A save now carries the version it was opened on and is refused if the file moved underneath it, with the reader told their text is still theirs.
    • A container release is health-checked on its public address, and the claim that it was not has been withdrawn. Measured at 323 of 347 samples over 90.5 seconds. The end state was correct every time, which is why nobody noticed. Still open in this build: what it means for you.
    • Only one update can run at a time, and the kernel enforces it. Four things could start one (the System updates page, the automatic loop, a fleet instruction, and klyrn update at a shell), and the checks between them were races whose loser did not fail but ran.
    • Jobs and Backups ask the server for one page instead of everything, and the ownership rule moved inside the query: a customer asking for a page of jobs used to get the newest jobs on the whole server and then only the few that were theirs. Measured: the jobs page on a phone went from 16,437 to 4,718 pixels tall.
    • A build log lost 84% of what the builder printed; a deployment never recorded the job that produced it, so no release could open its own build log; restoring a git application dropped its repository and branch; a deployment interrupted by a reboot stayed “building” for ever.
    • klyrn site --help and nine more never showed usage: with the daemon stopped they blamed the daemon, which is the moment you are asking. Help now works either way.
  2. 0.3.4-beta.12026-09-11

    System updates, from the server itself

    • System updates is a page of its own: what this server runs, what it could run, what every release changed, how the last attempt ended, and one button. It replaces the Updates section of Settings, and old links land on it.
    • The release history comes from the platform’s signed release index and is verified against the release key the build embeds, exactly as a manifest is. A history that does not verify is not shown, and installing never depends on it.
    • How the last update ended is kept and shown (“Update to X failed: the download failed”), with the error, a Retry and a Dismiss. It used to vanish with the file the updater wrote.

    Release channels and updating

  3. 0.3.3-beta.12026-09-10

    Applications built from a git repository

    • An application can start from a repository with a Dockerfile: KLYRN clones it, builds the image on your server, and deploys it by the digest it built, never by a tag. Everything after the image is the engine every other application already uses.
    • A build is treated as hostile code, because a Dockerfile is one. No container runtime socket, no host network, no privileges, a memory limit with no swap behind it, a CPU quota, a time limit, and a build context confined to the repository. Measured on a real server: the same build is killed under 32 MB and passes under 512 MB.
    • Private repositories use a deploy key KLYRN generates per application; the private half never leaves the server. A push can deploy through a signed webhook, and auto-deploy stays off until you turn it on.
    • “Deploy it now” on New application was sent by the panel and read by nothing, so every container application created from the panel sat undeployed until somebody pressed Deploy.

    How applications work

  4. 0.3.2-beta.12026-09-10

    Add a server to your fleet with one command

    • Add Server gives you one line to paste. A machine that already runs KLYRN gets the second half on its own.
    • The connection code is not a password: 160 random bits, single use, fifteen minutes, and the platform stores only its SHA-256. Redeeming it exchanges it for the server’s own check-in credential and destroys it in the same operation.
    • This changes nothing about the boundary the fleet has always kept: KLYRN never asks for a root password, an SSH key, or an open port. The server calls out.
    • Disconnect a server in the portal (hosting keeps running, only central management stops) and rotate its credential as a handover, so a lost reply cannot lock a machine out.
  5. 0.3.1-beta.12026-09-10

    Four releases the installed base could not see

    • KLYRN could not tell that beta.13 was newer than beta.4. The part after the dash was compared as text, and as text “beta.4” comes after “beta.13”, the same reason a folder sorts “10” before “2”. Every build from 0.3.0‑beta.2 to 0.3.0‑beta.9 asked for the newest beta, was told beta.13, decided what it had was newer, and reported that it was up to date. It was not lying; it could not see the release.
    • This release is numbered 0.3.1 for that reason. A fix shipped as another 0.3.0‑beta.N would have been just as invisible to the servers that need it, because it is the comparison that has to change and they are running the broken one. Only a higher number before the dash gets through.
    • Everything from 0.3.0‑beta.5 to 0.3.0‑beta.13 is included in it: container applications with the Ghost, Uptime Kuma and n8n templates, application Move, Store and WHMCS application hosting, per-account PHP-FPM masters so a kernel limit finally reaches PHP, kernel-enforced package limits, and central fleet updates (off unless you switch them on).
    • A failed update no longer leaves an older KLYRN in front of a newer database: both binaries are asked which schema they understand before anything is swapped. An update now checks your nginx configuration before it starts, instead of installing, failing, rolling back and reporting a failed rollback for a fault it did not cause.
  6. 0.3.0-beta.42026-09-07

    Two PHP pool defects, both of which took sites down

    • Changing a site’s PHP settings no longer takes the site down. Applying a pool removed the site’s socket and then reloaded php-fpm, which re-uses the descriptors it already holds and so could not recreate the path: nginx answered 502 until somebody restarted php-fpm by hand. KLYRN now restarts php-fpm when the socket does not come back, and only then reports failure. Present since sites became editable, and shipped in beta.1, beta.2 and beta.3.
    • The PHP memory-limit fix now reaches sites that already existed. beta.2 changed the pool template so a site can no longer delete its own memory limit, but an upgrade never re-renders a per-site pool, so upgraded servers kept the old one. Every site’s pool is now re-rendered at start, writing only where the bytes differ.
  7. 0.3.0-beta.22026-09-07

    Blank WordPress sites, an overridable memory limit, and the wrong install channel

    • Every WordPress site served a blank page. wp core download was called with --skip-content=false; --skip-content is a boolean, so WP-CLI treated it as set and fetched the tarball with no themes. The front page returned HTTP 200 with an empty body, which is why nothing that only checked the status code noticed. Acceptance now asserts the front page body is non-empty and looks like rendered WordPress.
    • A site could remove its own PHP memory limit. The pool rendered php_value[memory_limit], which is changeable from inside the site. It is now php_admin_value, and a test asserts every confinement directive is admin-enforced.
    • The public install command installed the wrong channel. get.sh defaulted to dev, so a stranger received a build months behind the beta, and it installed perfectly, so nothing told them. It defaults to beta and names the channel and version before downloading.
    • arm64 is refused at architecture detection, with the reason, instead of failing later with a message that reads like a broken release. No arm64 machine has ever run KLYRN.
    • An older build will no longer open a newer database. That is the rollback case; both stores now refuse, and name the way out.

    beta.3 carried no customer-visible change of its own; it is the build the PHP pool defect above was reproduced against, on a real server.

  8. 0.3.0-beta.12026-09-06

    First beta

    • A firewall and SSH centre: what is actually open, what is actually listening, and guardrails that refuse to lock you out of your own server.
    • Per-account CPU, memory and process limits enforced by the kernel through systemd slices. PHP-FPM pools and cron are not covered, and the panel says so on the account's own page.
    • Resource history, drawn without a chart library.
    • Hard filesystem quota capability detection, reported and never enabled silently.
    • klyrn doctor, a whole-server examination that works when the panel does not, and a support bundle that never reads a key, the database or a customer file.
    • Cron execution history: every run, with what it printed.
    • Selective restore: files only, or databases only.
    • Master key rotation, safe to interrupt.
    • Signed release channels, and an updater proven to refuse seven kinds of broken release.

    The first build on the public beta channel. It is tested and it is not finished: use a fresh or non‑critical server, and expect updates often. The public install command now installs 0.3.5‑beta.1.

    Release channels and updating

  9. 0.1.81-dev2026-09-06

    Disaster recovery, and backup keys that are never discarded

    • A versioned, encrypted recovery manifest in the backup destination: accounts, sites, domains, databases, cron and the most recent copies. Rewritten after every successful remote backup.
    • An unencrypted key fingerprint beside it, so a rebuilt server can name the key it needs instead of failing with "wrong key".
    • klyrn recover discover and klyrn recover run, reusing the per-site restore rather than adding a second implementation.
    • Backup key rotation that adds a key and keeps every earlier one. A backup restorable yesterday is still restorable today.

    Disaster recovery

  10. 0.1.80-dev2026-09-06

    WordPress staging

    • A real second site with its own vhost, pool, database and certificate, in the same hosting account as the live site.
    • Addresses rewritten through WP-CLI, so serialised PHP survives.
    • Kept out of search results by both WordPress and the vhost's own header.
    • The push backs the live site up first with the real backup engine, and stops if that fails.

    WordPress staging

  11. 0.1.76-dev2026-09-06

    Per-account disk measurement and limits

    • Usage and inodes measured per account every fifteen minutes, with a warning from 90%.
    • Uploads, extractions, copies, new archives, restores and new sites refused past the limit; delete, rename, chmod, write and mkdir still allowed.
    • Not a filesystem quota: a script the account runs itself can still write past the limit, and the panel, the CLI and the documentation all say so.

    Resource limits

  12. 0.1.63-dev2026-09-06

    PHP extension management

    • A catalogue of 22 extensions. There is no field anywhere in which to type a package name.
    • State read from php -m and the packaging, with the case folded, so a loaded extension is never reported as switched off.
    • Enabling is a job that tests the configuration before it reloads and puts the module back if anything fails.
  13. 0.1.57-dev2026-09-06

    DNS at the provider that is already authoritative

    • Cloudflare connected once, with the credential verified before it is stored and sealed at rest.
    • Records restricted to names KLYRN hosts (for every role, administrators included).
    • "Point this site here" writes the A records, skipping a name that is a CNAME rather than deleting somebody's record.

    DNS

  14. 0.1.53-dev2026-09-06

    Databases, domains, suspension and file operations

    • Database export and import as jobs, with a 24-hour retention and a decompression ceiling bounded by free disk.
    • Aliases and redirects, both covered by the certificate; a redirect gets its own server block on both ports.
    • Site and account suspension: the vhost and nothing else, answering 403, covering every name the site serves.
    • File copy, move and compress, with symlinks refused inside a tree and a free-space guard.
  15. 0.1.40-dev2026-09-06

    A site can be changed after it is created

    • PHP version, document root and www handling in one operation, because they end in the same reload.
    • Per-site PHP values from a validated allow-list, with the server default shown beside every field.
    • A pool that will not start puts the previous one back.
  16. 0.1.36-dev2026-09-06

    Release readiness

    • 29 panel routes, 6 portal routes and 10 admin routes audited in the browser at two widths in both themes, with a DOM audit that fails on findings a screenshot cannot show.
    • Initial panel JavaScript cut from 784.9 kB to 373.5 kB raw, 231.1 kB to 115.0 kB gzipped.
    • Customer Zero: the whole public path re-run on a wiped server, which found and fixed two installer defects.
  17. 0.1.33-dev2026-09-06

    Resellers, white-label branding and automatic updates

    • The reseller role, with its own customers, accounts and disk limits.
    • White-label branding per reseller, resolved for the sign-in page before anyone has signed in.
    • Automatic updates inside a maintenance window you choose.

    Resellers

  18. 0.1.28-dev2026-09-05

    WordPress maintenance from the panel

    • Core, plugin and theme status and updates from the site page, with a backup taken first.
  19. 0.1.25 – 0.1.27-dev2026-09-05

    Encrypted off-site copies, and sessions you can revoke

    • Remote copies encrypted on the server with XChaCha20-Poly1305 before they leave it, verified against MinIO including the wrong-key refusal.
    • Deleting a copy from the bucket on purpose, and never by accident: only a verified backup made on this server owns its remote copy.
    • Every session you are signed in on, listed and revocable from the account page.

    Copies made before 0.1.25-dev are plaintext.

  20. 0.1.21 – 0.1.24-dev2026-09-05

    Remote backup copies

    • Copies to an S3-compatible bucket, multipart above 1 GB.
    • The updater keeps the newest three state snapshots instead of one per update for ever.
  21. 0.1.20-dev2026-09-05

    Notifications

    • An SMTP relay configured in the panel, and alerts for open circuits, failed repairs, non-repairable failures, and certificate and backup failures.
  22. 0.1.15 – 0.1.19-dev2026-09-05

    Migration, two-factor sign-in and API tokens

    • Live migration from a cPanel server over SSH, and later without root on the source.
    • DirectAdmin backup import, feeding the same pipeline as the cPanel one.
    • TOTP with recovery codes, password change, and API tokens for scripts.

    Migrating to KLYRN

  23. 0.1.11 – 0.1.14-dev2026-09-05

    Users, roles, scheduled tasks and the first V1 acceptance

    • Users and roles, per-site scheduled tasks, and database users manageable from the panel.
    • The whole of V1 re-run on a wiped test server, including a reboot.
  24. 0.1.0 – 0.1.10-dev2026-09-05

    The foundation

    • The eleven-stage installer, the hardware profile and the tuning derived from it.
    • Sites: accounts, PHP and static sites, nginx, PHP-FPM, Let's Encrypt.
    • Databases and WordPress; Node.js applications with Git deploys and rollback.
    • Backups and restore, verified before they count.
    • Signed updates with automatic rollback, licensing with offline grace, and the self-repairing health engine.
    • The cPanel import engine, the file manager, and a panel hostname with its own certificate.

    Install

Method

Why this page looks like this.

A changelog is worth less than nothing if it lists things that did not happen. Three rules produced this page:

  • A version number appears only where one was recorded. KLYRN's builds are numbered in docs/STATUS.md and docs/COMPETITIVE-GAP.md as they ship. Work that landed after the last recorded number is listed as "not recorded" rather than given a plausible one.
  • Dates are commit dates, not release dates. The beta channel is public and installs today; the dates here are when the code was written down, which is why so many of them are the same day. No stable release has been published, so there is no stable release date to quote.
  • An item is listed once it has worked on a real server. The project's own rule is that a feature is marked done when it works on a machine, not when it compiles, and this page inherits it.

Once there is a stable release, this page changes to real versions with real release dates, and these development builds move to an archive.

Beta

One email when there is a stable version number.

The beta is public and installs today. The first stable release, and the prices of the paid editions, are announced to accounts and this list on the same day.

One email when pricing and the first release are announced. Nothing else.