The hosting control panel people switch to because everything else feels old.

The bootstrap script is deliberately tiny. It checks the OS and architecture, downloads the klyrn binary for your platform, verifies its checksum and ed25519 signature, and hands over to klyrn install. Everything from there is Go, not shell.

The installer is a state machine. Every stage can tell whether it already ran, apply itself idempotently, verify its own result against an objective post-condition, and roll back. State is saved after each transition, so an interrupted install resumes from the first unverified stage instead of starting over, and running it again on a finished server changes nothing.

1. preflightRoot, Ubuntu 24.04, at least 1 GB RAM and 10 GB free, ports 80, 443 and 7443 free, no conflicting panel or web server.
2. profileRecords CPU, RAM, swap, disk type and virtualisation. Every tuned value later derives from this.
3. os-prepareBase packages. A swap file if RAM is under 4 GB and none exists. Timezone and unattended-upgrades left alone.
4. identityThe klyrn system user, directories, the per-install secret key, config.json.
5. nginxInstalls nginx, takes ownership of its config, generates it from the profile, validates with nginx -t.
6. phpPHP 8.3 FPM with the common extensions from the Ondřej Surý PPA; the default pool disabled.
7. mariadbMariaDB 10.11 LTS, hardened through typed SQL, root over the Unix socket, tuned from the profile.
8. firewallufw: deny inbound, allow the SSH port that is actually in use, 80, 443 and 7443. It never locks you out.
9. kernelConservative sysctl limits and symlink and hardlink protections.
10. servicessystemd units for the core and the web tier; a self-signed panel certificate until you give it a hostname.
11. verifyEvery service answers: HTTPS on 7443, the core socket, nginx on 80, MariaDB, PHP-FPM. Prints the one-time setup URL.

No Apache and no .htaccess, on purpose: Apache costs memory per worker and re-reads .htaccess on every request. Every managed WordPress platform runs nginx, and WordPress is fine with it.

Every importer produces the same thing: a normalised, inspectable bundle of accounts, domains with their document roots and PHP versions, databases with users and grants, cron entries, certificates and DNS records. A planner turns the bundle into a plan you confirm, with conflicts named, unsupported PHP versions mapped to supported ones, and features without an equivalent flagged rather than silently dropped.

The applier runs as a job with independently retryable steps. The verifier compares file counts, sizes and checksums, and database row counts, then fetches each site on the new server so you can look at it before DNS moves. Transfers use rsync over SSH with bandwidth and I/O limits so neither server is destabilised.

1. Source
2. Collector
3. Bundle
4. Planner
5. Applier
6. Verifier

In progress. Import from a cPanel archive is part of V1. SSH-driven cPanel migration with low-downtime sync and DirectAdmin import follow in V1.5; Plesk in V2. Mail settings are recorded in the bundle so nothing is lost, but mail hosting itself is not part of V1.

Checks run on a staggered schedule: nginx is active, its config valid and answering; every PHP-FPM version; MariaDB; the panel itself; each Node app; disk space and inodes per mount; memory and swap pressure; load; certificate expiry; time sync; the firewall.

When a check fails, the health engine applies a bounded repair: restart the unit, regenerate the nginx config from the database, re-issue a certificate, re-enable a unit that was disabled. A circuit breaker allows at most three repairs per check in thirty minutes with back-off, then marks it as needing a human. Every attempt is recorded with its reason, action, result and duration.

It never deletes data, kills customer processes or changes firewall rules.

klyrn-web handles HTTPS, sign-in, sessions and rate limits as an unprivileged user. It has no shell, cannot open the database and cannot execute anything. klyrn-core runs as root and exposes a closed set of typed operations over a Unix socket: create site, create database, issue certificate. Each has its own validator and authoriser, and core re-checks who is asking against its own records, so a compromised web tier cannot claim a role it does not have.

There is no dashboard of cards. A fixed rail, a command bar that jumps to anything, and lists that open into details. Creating a site is a domain, a type and a button; PHP version, document root and profile are one click away, not in the way.

Long operations run as jobs with step-by-step progress and a readable log, streamed live. Every list has a real empty, loading, partial and error state, and the interface never shows a number it made up. Light and dark. Inter for text, JetBrains Mono for paths and values, tabular figures for anything that refreshes.

The panel serves its own TLS on port 7443, independent of nginx, so a broken web server never locks you out of the tool you need to fix it. There are no default credentials: the setup token is printed once on the console, and the setup endpoint is disabled after the first admin exists.

Mail is not in V1 because it is the most reputation-sensitive subsystem there is and the least differentiating; shipping it half-done would hurt your deliverability. Local authoritative DNS is not the default because DNS on the hosting box is a single point of failure; KLYRN talks to your DNS provider instead.