Keel Linux

Home / Roadmap

Roadmap

One layer at a time

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, 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.

  1. Phase 0: sharpen the axe

    0 of 5 done

    • Record the decisions, 0023 to 0040
    • Map them against 0000 to 0022; the maintainer confirms the review notes
    • Specify the manifest format, the pivot of backup, monitoring, upgrade, replication and discovery (tracker#39; version 1 decided in 0041)
    • The maintainer validates the WordPress test image for simple and cloud simple
    • An attended release replaces the published layers that still carry private keys

    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.

  2. Phase 1: Keel Core

    1 of 7 done

    • WireGuard in Core (0024)
    • CrowdSec in Core, installed and disabled (0029)
    • etcd overlay present and stopped (0025, 0036)
    • YAML always emitted, complete with defaults (0027)
    • stable and testing tracks declared in the YAML (0039)
    • Overlays shipped as .deb from the Keel repository (0036, 0039)
    • Simple and advanced mode screen (0028)

    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.

  3. Phase 2: data appliances, standalone and paired

    0 of 5 done

    • MariaDB standalone and paired; the pair, seeding and read-only replica are mostly done in keel 0.11
    • PostgreSQL standalone and paired
    • Redis standalone and paired
    • The semi-synchronous setup for MariaDB and the timeout policy for both engines (0031)
    • Automatic failback after full catch-up, for the pair; the default stays the operator's, manual (0031)

    Done when each engine passes a two-container gate in cloud simple: write on the primary, read on the standby, commit latency and the synchronous or semi-synchronous fallback measured, promotion by hand.

  4. Phase 3: Keel Web

    0 of 3 done

    • WAF: the Coraza connector, ModSecurity v3, or Coraza as a proxy (0030)
    • Anubis packaged in the Keel repository
    • nginx overlay and the Keel Web recipe; Coraza and Anubis disabled in simple

    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.

  5. Phase 4: runtimes, and WordPress on Keel PHP

    0 of 3 done

    • php-fpm overlay; Keel PHP is Keel Web plus php-fpm (0023)
    • WordPress as the first application built from a manifest, which retires Apache for WordPress (0034)
    • python, ruby, nodejs and go overlays (0036)

    Done when WordPress on Keel PHP passes the appliance gate in simple and cloud simple, built from its manifest, with no Apache in the image.

  6. Phase 5: mesh control plane

    0 of 7 done

    • etcd registry: key layout and node announcement (0025)
    • Installation by discovery (0026)
    • Cloud advanced on three nodes, election and fencing (0028)
    • Automatic failback after full catch-up on three nodes; the operator still chooses, default manual (0031)
    • Service address controller rewriting AllowedIPs from etcd (0029)
    • Syncthing overlay, send-only and receive-only flipped on promotion (0032)
    • Monit summary to etcd, mesh alerting by watch (0040)

    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.

  7. Phase 6: applications by manifest

    0 of 3 done

    • Odoo by manifest, updated with apt (0039)
    • Nextcloud by manifest
    • Mastodon as the reference proof (0035)

    Done when each passes the gate in simple and cloud advanced from its manifest alone plus its inithook, Mastodon last.

  8. Phase 7: object storage and backup

    0 of 4 done

    • Garage packaged; s3 overlay with zones from the site label (0038)
    • Keel Backup appliance (0037)
    • TKLBAM backend abstraction targeting Keel Backup
    • Periodic restore test into a throwaway container, reported to etcd

    Done when an application is backed up from its standby to Keel Backup in another site, and a scheduled restore test succeeds and is visible in etcd.

  9. Open architecture items

    • DNS successor for nodes behind NAT with changing IPv6 prefixes; PowerDNS fed from etcd is likely, not decided (0024)
    • Elasticsearch or OpenSearch (0033)
    • MongoDB and CouchDB: deferred