What KLYRN does not do.

KLYRN is tested and it is not finished. The current build is 0.3.5‑beta.1 on the public beta channel, and it is what the install command installs. There is no stable release, and no date has been announced for one.

Three things follow from that, and they are the terms on which the beta is offered:

• Use a fresh server, or one whose contents you can afford to lose. Not a machine that is already running something you care about. The installer refuses a server that already has another panel, Apache, or an nginx or MariaDB it did not configure, so it will not quietly move in beside them.
• Expect updates, and expect to take them. Fixes land on the beta channel, and several betas so far have closed a defect that could take a real site down or damage a file. Every one is listed, with its cause, on the changelog. One release could not even be seen by the servers that needed it, which is why the numbering jumped to 0.3.1.
• Keep your own copy of anything irreplaceable. KLYRN takes backups, verifies them by listing the archive back and checking every checksum in its manifest, and they have been restore-tested. A beta is still not the place to hold the only copy of something.

One operating system is the reason the tuning, the package names and the service units can be exact rather than defensive. Debian 12 and 13 are planned for V1.5. Nothing else is.

arm64 is not supported. A binary can be built for it and the release format has fields for it, but no ARM machine has ever run KLYRN: the package names, the PHP and MariaDB repositories and the systemd unit behaviour are all verified on x86_64 only. The installer refuses an ARM machine at architecture detection and says so, rather than fail later with something that reads like a broken release.

The rest of what the installer checks (memory, disk, ports, root, outbound network) is on Requirements, and it checks all of it before it writes anything.

These are refusals with reasons, not gaps waiting to be filled.

No email hosting

Not in V1, by decision. KLYRN will not host your mailboxes. Keep them where they are: your MX records never change, and nothing KLYRN does touches mail delivery. A migration counts the mail domains and mailboxes it finds and reports them in the plan, so you know what is staying behind before you move. A mail server is a permanent deliverability and security burden whose IP reputation starts at zero.

No DNS hosting

KLYRN is not a nameserver. You point your domain at the server yourself. Where a provider is already authoritative for the name and KLYRN can talk to it, it edits the records there instead. See DNS. A panel that is also a nameserver takes every domain it names down with it.

No phpMyAdmin

Databases are created, exported and imported from the panel and the CLI. KLYRN does not bundle phpMyAdmin: a large PHP application with a long history of vulnerabilities, running next to every customer's data, is not something to install by default.

The reasoning in full is on the security page.

No archive produced by a real cPanel or DirectAdmin server has ever been fed to KLYRN's parsers. Every fixture in the test suite was written from the vendors' published documentation. A fixture written by the author of a parser tests that parser against their belief about the format, not against the format. A real archive from a real server is the next step, and it has not happened.

The parsers, the .htaccess translation and the pre-cutover report all have tests and the tests pass. Every route has been run end to end against a stand-in source that produces a genuine archive layout and answers the same commands. That exercises the whole pipeline. It does not exercise cPanel.

So the practical rule, which is the same one we would give a friend: keep the old server running, check the imported copy on the new server before you touch DNS, and leave the source alive for a week afterwards. KLYRN is built for exactly that order: nothing is installed on the source, nothing is written on the destination until you have read the plan, and the old server keeps serving until you change a record.

What a migration carries, what it only reports, and what “verified” means

KLYRN deploys a container application by replacing the container on the port nginx proxies to, so the new container binds that port before its health check runs. Between the container starting and the check failing, the public address serves a release that never passed. Measured on a real deployment, polling four times a second: 323 of 347 samples over 90.5 seconds.

The end state is correct every time (the previous release is restored and the deployment is marked failed), which is exactly why this went unnoticed: looking after the job has finished shows the right answer. The CLI used to claim the opposite, “the previous release keeps serving until the new one answers”. That sentence is gone, and a deployment that fails its health check now reports how long its window was.

Closing it means the new container coming up on a port of its own with nginx moving to it only after the check passes: a change to the deployment engine for every container application, not a patch. It is not in 0.3.5‑beta.1. Until it ships, deploy behind a maintenance window if a bad release reaching visitors for ninety seconds would matter to you. Websites, WordPress sites and Node.js applications are not affected: this is the container deployment path only.

A signed-in panel session is meant to end after twelve hours of no use. It does not: the twelve-hour value is declared in the build and read by nothing, so the only limit a session has ever had is the seven-day absolute one. A cookie copied off a laptop on Monday still works on Friday, having been used by nobody in between. The security page said “12-hour idle” until today, and it was wrong.

Everything else about sessions is as described: 256-bit identifiers stored server-side, sent as Secure, HttpOnly, SameSite=Strict cookies, rotated on sign-in and on privilege change. The seven-day limit is enforced. This is a limit that was announced and never applied. It is not a session that never ends.

Idle expiry is enforced in the next release and is not in 0.3.5‑beta.1. Until it ships, treat a panel session as valid for seven days: sign out on a machine you do not control, and use the panel’s Security page, which lists every session and revokes them one at a time or all the others at once.

Each hosting account gets its own systemd slice, and a CPU, memory or process limit set on it is enforced by the kernel. It reaches what runs inside that slice: Node.js application units, and (since each account got a PHP-FPM master of its own) that account's PHP workers. Measured: a PHP script allowed to allocate freely was killed by the kernel at about 389 MB under a 384 MB limit, and a spin loop under a 25% quota ran at 25.00% of one core over ten seconds.

Cron is the workload it does not reach, and that is not scheduled to change. Cron runs its jobs from /etc/cron.d under the system cron service rather than as units of their own, so a per-account cgroup cannot see them. An account's cron job is bounded by nothing but the server.

Cron jobs are children of the system cron service rather than units of their own, which is why a per-account cgroup cannot reach them. The panel says this on each account's own page rather than implying the limit is total.

Resource limits, measured

KLYRN measures each account's usage and refuses the operations that would push it over: uploads, extractions, copies, new archives, restores and new sites. Deleting, renaming and editing stay allowed, because deleting is the way back under the limit.

It is not a hard stop. A script the account runs itself writes through the kernel, not through KLYRN, and KLYRN is not in that path. The next measurement will show that it did, and the health view and the account's own page will say so.

A real filesystem quota would stop it, and it needs /home mounted separately with quota support. On a typical VPS with one root filesystem, enabling that means rewriting the root mount options and quota-checking the whole disk on a live server. KLYRN detects whether the machine could support it and reports the answer; it never turns it on silently. Hard quotas are planned for V1.5.

Free is real and installable today: one server, five sites, the whole panel, no card. Pro, Business and Enterprise cannot be bought. No price has been confirmed for sale and there are no payment instructions, so an order is refused rather than turned into an invoice nobody can pay.

Two things need a licence that does not exist yet: reseller accounts, which need Business or Enterprise, and the fleet features that ship with the central platform in V2. Everything else on this site is in the free beta.

What each edition will include, and the one email you get when prices are set

A reseller is meant to see their own customers and nothing about the machine underneath them. In 0.3.5‑beta.1 the code treats a reseller as staff, so a reseller is shown the server's hostname and public address, its CPU, memory, disk and network graphs, its thread count and memory, and the health tally. The panel prints "whoever runs this server can see which" underneath a number it is showing to somebody who does not run the server.

Two further gaps are the same decision seen from other angles. The attention list's "provisioning failed" query carries no owner clause, so a reseller is shown the last six failed provisions on the whole machine, each titled with another tenant's customer email address. The panel's live event stream is one stream fanned out to every signed-in staff browser, so a reseller's browser receives the machine's update state and other tenants' domain names, readable in the network tab.

Nobody can reach this today without a licence that is not on sale. Reseller accounts need Business or Enterprise, and the free edition refuses to create one, so a single-operator server is not exposed by it. It matters the moment resellers can be bought, and it is fixed before then: the next release scopes a reseller to their own tenancy at the backend, refuses the server graphs to everyone but an administrator, and filters the event stream per subscriber.

Ask the server first. Both of these answer even when the panel does not:

klyrn doctor                    # twenty-two checks, failures first
klyrn site diagnose example.com # every probe in the order a request travels

They name causes rather than symptoms, and a site diagnosis offers a named repair when it has one. Start from the symptom you have if you would rather not read a reference first.

If that does not settle it, report it through the account you installed with, at my.klyrn.com. Useful things to include: what you did, what you expected, what happened, and the output of klyrn doctor. klyrn doctor --bundle writes a redacted support bundle that never reads a private key, the panel database or a customer's file, and tells you how many values it removed and of what kind. Read it before you send it: it is your server.

There is no published support address or coordinated-disclosure address yet, and there is no promised response time. Saying otherwise would mean somebody believes they have reported something when they have not. For a suspected security problem, use the reporting page, and do not include keys, passwords or customer data.

Nobody from KLYRN will ever ask you for your backup encryption key, your master key, any private key, a database password, your panel administrator password, or your account password. Support does not need them and cannot use them. If somebody asks, whatever they claim to be, the request is illegitimate.