WireGuard in Core; the rest decided, 0024
+Two nodes joined, in testing WireGuard in Core; the rest decided, 0024
keel network wireguard key prints this node's public key and never the private one./128 route in AllowedIPs that a controller moves to the active node. Replication and node-to-node traffic always use the nodes' real addresses.Phase 5 has started. Two Keel Web nodes in different locations are joined over a WireGuard overlay, declared in each node's instance spec and confirmed through the network safety window. Next is a one-command join, keel mesh invite on a node of the mesh then keel mesh join on the new one (decision 0048, in review), and etcd forms when the third node joins.
Open: the successor to HubDNS for nodes behind NAT whose IPv6 prefix changes. A PowerDNS overlay fed from etcd is the likely shape, not yet decided.
Decided, 0037 and 0038; Phase 7
Every appliance is secure by default and can join a private cloud on day one.
A fork of TurnKey Linux 19 (Debian 13) that turns single-machine appliances into building blocks of a real cloud: small components that run alone or together, replicate across sites, fail over, and are upgraded with apt. IPv6-first, so every node has a routable address of its own, and declarative, so every machine is described by one YAML file that Keel applies and re-applies to the same result.
@@ -382,12 +382,52 @@What landed in two days of work. Everything here is on the testing channel and not meant for production.
+The earlier test images and layers carried keys made at build time, so every machine made from one shared them. They were withdrawn and rebuilt. A scan on every layer and image now checks that none carries SSH host keys, TLS private keys, a Webmin certificate or snakeoil keys, and every machine generates its own at first boot.
+ +archive.keellinux.org is signed and has two tracks: trixie-testing, where everything lands first, and trixie, the stable track. Promotion to stable is a maintainer's act.
Images are built from Debian and the Keel archive only, with no TurnKey archive. The TurnKey tools Keel still uses, turnkey-ssl, netinfo, conffile, sysinfo, version, tkl-installer and the dhcpcd glue, are now Keel forks, and turnkey-ssl no longer ships a key. TKLBAM and the TurnKey Hub agent are gone; Keel Backup and Keel Cloud replace them later.
+In simple mode Keel Web serves HTTPS out of the box with the machine's own certificate, a Keel placeholder page and Keel error pages. Let's Encrypt is set up from the console, prefilled from the instance spec. Cloud mode adds the Coraza WAF and the Anubis bot challenge.
+First boot asks for the FQDN and offers to keep a root password the hypervisor already set. Unattended, it runs to the end without hanging, and it installs security updates from Debian Security without ever blocking the boot. systemctl --failed is clean in containers.
Phase 5 has started. Two Keel Web nodes in different locations are joined over a WireGuard overlay, declared in each node's instance spec and confirmed through the network safety window. Next is a one-command join, keel mesh invite then keel mesh join (decision 0048, in review), and etcd forms at the third node.
There is no release for end users. Layers, Proxmox templates and packages are served from mirror.keellinux.org and archive.keellinux.org for testing, and the test images are not meant for production.
+There is no release for end users. The current images are signed testing pre-releases, not meant for production: Keel Core 19.0-8 and Keel Web 19.0-3, built on 3 October 2026. Each is a .tar.zst for LXC, on its GitHub release and on mirror.keellinux.org, and listed in the Proxmox template index. Decision 0043 makes the ISO the second release format.
Packages come from archive.keellinux.org, signed, on a testing track that everything reaches first and a stable track the maintainer promotes to.
The build host reproduces unmodified TurnKey 19.0 from the forked repositories, which is the baseline every change is measured against. keel inspect, keel diff and keel spec apply run on the test images, and a MariaDB pair, with seeding and a read-only replica, is mostly done in keel 0.11.
The composition architecture on this site was decided on 30 September 2026. Where a point says decided or goal, it is on the roadmap and not yet in the code.
WireGuard is in Core. Next: CrowdSec installed and disabled, etcd present and stopped, the YAML always emitted, overlays shipped as .deb.
Nginx, Coraza and Anubis packaged in the Keel repository; plain Nginx in a simple installation, the full pipeline in an advanced one.
Version 1 is decided. The first step is its reader, keel manifest validate and keel manifest show, with Core and Web as fixtures.
Two Keel Web nodes are joined over WireGuard, declared in each node's spec. Next: a one-command join, and etcd at the third node.
In testing as signed pre-releases, with the appliance manifest. Keel Web serves HTTPS in simple mode; Coraza and Anubis come with cloud mode.
The first application built from a manifest, with no Apache in the image.
Decisions: 0023 to 0040 on the tracker, and the manifest, tracker#39.
Every phase ships something testable, and a phase is done only when its criterion holds on a built image, not on a machine assembled by hand. The focus now is Keel Core and Keel Web.
-A copy of tracker#46 as of 2026-09-30. The tracker is the source; where the two differ, the tracker is right. Decision numbers link to their issue on the tracker.
+A copy of tracker#46 as of 2026-09-30, with progress notes from 2026-10-03. The tracker is the source; where the two differ, the tracker is right. Decision numbers link to their issue on the tracker.
Progress. The layers and images that carried shared keys were withdrawn on 2 October, and signed rebuilds replaced them on the testing channel: Keel Core 19.0-8 and Keel Web 19.0-3.
Done when the manifest schema is reviewed with WordPress, Odoo and Mastodon examples, the WordPress test image passes the maintainer's test, and no published layer carries a shared key.
.deb from the Keel repository (0036, 0039)Progress. Keel Core is in testing as a signed pre-release, built from Debian and the Keel archive only. First boot asks for the FQDN, runs unattended without hanging, and installs security updates without blocking the boot.
Done when a Core image boots in simple installation, emits a YAML that re-applies as a no-op, runs no etcd and no active CrowdSec, and upgrades one overlay with apt upgrade on the testing track.
Progress. Keel Web is in testing as a signed pre-release. In simple mode it serves HTTPS with the machine's own certificate; cloud mode adds Coraza and Anubis.
Done when Keel Web in advanced mode blocks a Core Rule Set test payload, challenges a browser through Anubis, lets exempt crawlers through, and in simple mode is plain Nginx.
Progress. Under way. Two Keel Web nodes in different locations are joined over a WireGuard overlay, declared in each node's instance spec. Next: a one-command join, keel mesh invite and keel mesh join (decision 0048, in review), and etcd at the third node.
Done when a three-container gate installs the second and third node by discovery, fails over automatically, moves the service address, flips the Syncthing folders, fails back after catch-up, and reports each node's Monit summary through etcd.
An image that carries a private key hands that key to everyone who downloads it. Keel removes them in three places, so that none depends on another being remembered. Built; test layers to be republished
+An image that carries a private key hands that key to everyone who downloads it. Keel removes them in three places, so that none depends on another being remembered. In the current testing images
The test layers on the mirror were built before the fix, and an attended release replaces them (Phase 0 of the roadmap). Until then the boot unit is what protects a machine made from one. ISO and VM images still ship the build's machine-id (tracker#24).
+The test images and layers published before the fix carried keys made at build time. They were withdrawn on 2 October 2026 and replaced by signed rebuilds that pass the scan; the notice on the mirror says how to give a machine made from an old one its own keys. The ISO build now leaves the machine-id empty too (tracker#24).
An operator can depart from a default on one machine, in the spec. A disabled overlay is still installed, so turning it on is a change to the spec, not a new image.
+In the current testing image, Keel Web in simple mode serves HTTPS out of the box with the machine's own certificate, a Keel placeholder page and Keel error pages. Let's Encrypt is set up from the console, prefilled from the instance spec. In testing
Every image rebuilds from the project's own archive: a dated, pinned pool, verified by the build before it is read. What Debian 13 does not carry, Keel builds from source and signs in the same repository: Coraza's Nginx connector, Anubis and Garage. Anubis and Garage have packaging in progress in Debian, and Keel coordinates with those efforts rather than packaging in parallel. Decided, 0039
+The testing images are built from Debian and the Keel archive only, with no TurnKey archive. The TurnKey tools Keel still uses, turnkey-ssl, netinfo, conffile, sysinfo, version, tkl-installer and the dhcpcd glue, are Keel forks published there, and turnkey-ssl no longer ships a key. In testing
+The archive, archive.keellinux.org, has two tracks: trixie-testing, where everything lands first, and trixie, the stable track. Promotion to stable is a maintainer's act. Images and the archive are signed, and the keyring is at archive.keellinux.org/keel-archive-keyring.asc.