cloud native OSPulsePublic preview
Rolling release · commit 2566bf2 · generated

Guide

What a cloud native OS is, how the Pulse was made, and how to read the matrix.

by Mauro Morales, CNCF Ambassador

I am one of the maintainers of Kairos and Hadron, two of the entries, and I work for Spectro Cloud. See Who is behind it.

Data as of The newest date a cited source was read. Profiles collected 15 Sep 2026 to 14 Oct 2026. Sources were last re-read in full on 22 Sep 2026. A profile collected after that date was read once, on its collection date.

What is a cloud native OS?

New to these terms? The glossary defines each one.

The mismatch

A general-purpose operating system, such as Ubuntu, Debian, Fedora, Red Hat Enterprise Linux or SUSE Linux Enterprise Server, is built to do anything. You install it once and then groom it for its entire lifespan: you add packages, edit configuration files and upgrade it piece by piece on the running machine.

Cloud native pushes applications toward the twelve-factor model: stateless, disposable, easy to scale and to replace. Yet a lot of cloud native infrastructure still runs on a general-purpose OS. Two of the three big managed Kubernetes services default to one: AKS to Ubuntu, and EKS managed node groups to Amazon Linux 2023. That is a mismatch. We like to think the machines under our applications are cattle, because we configure them automatically. The truth is that they are automated pets, each one still groomed on its own.

Configuration management tools such as Ansible, Puppet or Chef help, but automation alone cannot fix the root problem. They describe changes to apply to a machine, not the whole state of the machine. Anything they do not manage still changes it, from a package someone installed by hand to a dependency that moved upstream. So two nodes set up from the same playbook a month apart can end up different, and the difference grows with every change. That is drift. There is also no single version of the OS that you can provision again on day 0, when a node is first set up, or roll back to.

A different approach

A cloud native operating system takes a different approach. It is built for one job: running cloud native workloads on machines you manage as a fleet. It treats the OS the way container images treat an application. The whole OS is one versioned artifact. Every node is provisioned from the same version, a new version replaces the old one instead of changing it in place, and the previous version is still there if the new one fails.

Side by side:

General-purpose OScloud native OS
UpdatesIn placeAtomic
What a version namesA release, such as 24.04. Each node's real content is its own set of package versionsThe whole OS: one version, the same on every node
The running systemWritableImmutable*
Undoing an updateDowngrade packages, boot a previous filesystem snapshot, or rebuild the nodeRoll back: boot into a previous version
First installAn installer, or an automated installA versioned image
ConfigurationApplied on top and changed over time, so nodes can drift apartWritten config, applied at install or first boot, and on some systems applied again later
Main jobAnythingRunning cloud native workloads

* Only part of the OS is read-only, and which part varies by system. See Immutable in the glossary.

The five inclusion criteria

Most rows of that table are also a test. An OS is in the matrix when it meets all five inclusion criteria:

  1. Atomic updates (versioned OS). The OS version is one artifact, built once, that every node in a fleet runs. A fleet updates or rolls back by pointing it at a version, for example an OCI image, an image file or an OSTree commit. A node that assembles its own update from packages does not meet this rule. It is enough that the project documents a way to run it like this.
  2. Immutable at runtime (read-only OS files). The OS part, the root or /usr, is read-only on a running node.
  3. Rollback (to a version). Rollback goes back to the previous OS version, the artifact the whole fleet ran. Each node keeps that version locally, ready to boot. It is a rollback to a version, not to a snapshot of one node.
  4. Config-driven provisioning. A node sets itself up from a written config when it is installed or first boots, with no interactive install. Some projects apply the config again at every boot, on demand, or by reconcile. The config can be one file or several. The old name, Declarative provisioning, stays as an alias.
  5. Kubernetes ready. The project, or its vendor, documents running Kubernetes on it: bundled, installed on it, or as the node OS of a Kubernetes service. A framework such as Kairos or bootc meets this rule through the images built with it. Running containers alone is not enough.

Eleven entries meet them today: Azure Container Linux (ACL), bootc, Bottlerocket, Container-Optimized OS, Elemental, EVE-OS, Fedora CoreOS, Flatcar Container Linux, Kairos (with Hadron), Talos Linux, and Ubuntu Core. R3 (Rollback, to a version) is not yet documented for Azure Container Linux and Container-Optimized OS, so for those two the entry rests on the other four criteria.

A general-purpose OS can be made to work this way. With enough configuration, and tooling built around it, you can produce images, update them atomically, keep the OS read-only, roll back and provision from a written config. Many teams do. The Pulse does not say that is the wrong choice. It lists the projects built to meet the five criteria by design, so you do not have to configure the OS yourself or build that tooling to get there.

Openness is not a criterion. A closed or single-vendor OS that meets the five criteria is in, and the matrix shows its governance next to every other entry.

Some projects sit beside the matrix. Alternative paradigms aim at the same goal and do not meet the first four rules as the project ships them: NixOS, Unikraft and the Yocto Project. Worth mentioning lists public work with nothing released to profile yet. Considered and excluded names released projects that fail a criterion, with the reason. Conventional mutable distributions are out, even when they are a common Kubernetes node OS like the defaults on AKS and EKS, because they fail the first two rules. The methodology gives the full reasoning, and the source for how each entry meets the Kubernetes rule.

Misconceptions

MisconceptionImmutable means the whole system is read-only.
In factOnly part of the OS is read-only: the whole root filesystem on some systems, only /usr on others. Data and some configuration stay writable, and some of that is writable only until the next boot, through an overlay or an in-memory filesystem. A system that was read-only everywhere could not store data or run workloads. The glossary has the details, and the matrix's Update unit column shows what one update replaces on each entry.
MisconceptionAPI-only access means a smaller attack surface.
In factAn API is an attack surface too, just like SSH. What API-only access gives you is a bound and a record: you can only change what the API exposes, unless the API allows arbitrary execution, and API calls are easier to log than shell sessions. A shell is more flexible and works with familiar tooling. Neither is more secure by default. The matrix's Node access column shows which each entry offers.
MisconceptionA rollback undoes everything.
In factA rollback restores the part of the system the update replaced, and that part differs by design. Flatcar's A/B update covers /usr, so a bad change to /etc survives a rollback. Bottlerocket keeps settings in an API datastore outside the image, so they are not part of what rolls back. The Flatcar and Bottlerocket pair walks through it, and the Update unit column shows it for every entry.
MisconceptionAtomic updates mean no downtime.
In factAtomic means all or nothing: the new version applies as a whole, or the old one stays. It does not mean zero downtime. On most entries the new version takes effect at the next reboot, so the node goes down briefly. Keeping workloads running is a cluster-level job: draining nodes and rolling the update through the fleet.
MisconceptionA signed update means a trusted running system.
In factA signature on an update protects the download. It does not stop a machine from booting a disk that was changed afterwards. That is the job of the boot trust chain: Secure Boot checks the first boot component, measured boot records each stage, and the chain covers the running system only when the final root filesystem is part of what was signed and measured, either because the whole OS is in the image (a USI) or because the root filesystem's dm-verity hash is.
MisconceptionAn immutable OS cannot be customized.
In factIt is customized differently: you change the image, not the running system. Some entries add software through system extensions, some let you build your own image from a base you choose, and some allow layering packages on top, which their own docs may discourage. The matrix's Adding software to the OS and Bring your own distro columns and each project's data sheet show what each one allows.
MisconceptionElemental and openSUSE MicroOS are the same thing.
In factThey are two projects with different jobs. Elemental is Rancher's OS management stack: a toolkit and an operator that build and maintain node operating systems from container images, and let Rancher Manager manage them. Its documentation describes the stack as “a handful of packages on top of SLE Micro”. openSUSE MicroOS is a distribution, described as “Micro Service OS built by the openSUSE community”. Both have a data sheet in the Pulse. Elemental is an entry: it rolls one OCI image to every node in a fleet. openSUSE MicroOS is not in the matrix, because each node builds its own update from packages, which does not meet the first criterion. The reason is in the methodology, section 11, item 12.
MisconceptionFedora CoreOS and bootc are the same thing.
In factToday they are not. Fedora CoreOS fetches its updates as an OCI image, but it applies them on disk as an OSTree deployment through rpm-ostree. The Fedora change proposal says it keeps using rpm-ostree “and not yet bootc”. Fedora bootc is a set of base images that you derive from. Fedora's own comparison says Fedora CoreOS “generally emphasizes users configuring an image pre-built by Fedora”, while Fedora bootc “emphasizes users deriving from our container base image”. Fedora has started a working group to bring the two together, with Fedora 46 as the goal, and it is still working out the technical direction. The upstream bootc project is separate and stays independent of any one distribution. See the Fedora CoreOS and bootc data sheets.

Start from your situation

New to immutable operating systems, with a constraint you already know? Pick the situation closest to yours. Each one lists the questions that matter for it and opens the matrix filtered to the systems that meet them. The blocks name no project. Each question opens a matrix filter or a matrix column: the values are there, and the conclusion is yours. A question the matrix does not cover yet says so.

Use case

If you run machines at many remote sites over weak links

  1. When a machine boots a bad update with nobody on site, does it undo the update by itself?Matrix filter: Automatic rollback, Yes
  2. What does that undo revert: the whole OS image, or only part of it?Matrix column: Update unit
  3. Can the update source live on your own network?Matrix filter: Self-hostable update source
  4. Which of your board architectures have released images, not only build tooling?Matrix filter: Architecture, arm64
  5. How does a new machine get its first configuration with no one at the keyboard?Matrix filter: Day-0 path, PXE
  6. Can you recover a machine that has no network?Not in the matrix yet
Use case

If you use the node OS your cloud provider gives you

  1. Is the OS the default node image on your managed Kubernetes, an opt-in, or the only choice in some cluster modes?Not in the matrix yet
  2. Who starts an update: the node, you, or the managed service?Matrix column: Fleet upgrade paths
  3. Does the image run anywhere outside that one cloud?Not in the matrix yet
  4. If a new node image fails, does the node revert, or does the service replace it?Matrix filter: Automatic rollback, Yes
  5. Who holds the project assets, and who sells support?Matrix column: Who holds the assets
Use case

If you run Kubernetes on your own hardware with Cluster API

  1. Is there a Cluster API provider for the OS, of which type, and who maintains it?Matrix column: Cluster API
  2. Is Kubernetes in the image, or does your bootstrap install it?Matrix column: Kubernetes
  3. Can the OS and Kubernetes upgrade separately?Not in the matrix yet
  4. How does a new machine get installed with no one at the keyboard?Matrix filter: Day-0 path, PXE
  5. Can the update source live on your own network?Matrix filter: Self-hostable update source
Use case

If you run in a regulated or air-gapped environment

  1. Can a node check that an update is signed before it applies it?Matrix filter: Update signature check, Possible
  2. Can updates come from a mirror on your own network, with no call to the project or vendor?Matrix filter: Self-hostable update source
  3. What does the project publish about what is in the image and how it was built?Not in the matrix yet
  4. Are FIPS builds available, and from whom?Not in the matrix yet
  5. Can a machine be recovered with no network?Not in the matrix yet
  6. How long is a release supported, and is there a published end date?Matrix column: Support model
Use case

If you run GPU or AI workloads

  1. Are GPU drivers published for your accelerator and your architecture?Matrix column: AI accelerators
  2. How does a kernel module reach an image the node cannot change at run time?Matrix column: AI accelerators
  3. Do the driver and the kernel update together, as one unit?Matrix column: AI accelerators
  4. With Secure Boot on, how do out-of-tree modules get signed?Not in the matrix yet
  5. If a driver update stops the node from booting, does it revert by itself?Matrix filter: Automatic rollback, Yes
Use case

If you build a device that ships with the OS inside

  1. Who builds and patches the image you ship: the project, or you?Matrix column: Who owns the artifact
  2. Can you start from a base distribution you choose?Matrix filter: Bring your own distro, Yes
  3. Which of your board architectures have released images, not only build tooling?Matrix filter: Architecture, arm64
  4. How is the image written at the factory, and how does it get its first configuration?Matrix filter: Day-0 path, Disk image
  5. After a bad update in the field, does the device undo it alone, and can it be reset?Matrix filter: Automatic rollback, Yes
  6. How long is a release supported, and who sells support beyond that?Matrix column: Support model
Use case

If you run a homelab or want to learn how these systems work

  1. Does it install on the hardware you have: a mini PC, a single-board computer, a VM?Matrix filter: Day-0 path, ISO
  2. Do you want Kubernetes in the image, or to add it yourself?Matrix column: Kubernetes
  3. What does an update replace, and what survives it?Matrix column: Update unit
  4. If an update breaks the boot, does it undo itself?Matrix filter: Automatic rollback, Yes
  5. When something goes wrong, can you get a shell, or only an API?Not in the matrix yet
  6. Who holds the project assets, and how open is its governance?Matrix column: Who holds the assets

Looks alike, differs on

Pairs of entries that share a design and part ways on one property a reader acts on.

Looks alike, differs on

Both switch A/B partitions. They differ on what an update replaces, so on what a rollback undoes.

Flatcar Container Linux
Bottlerocket
Shared
An update is written to the inactive partition set, then the boot target flips. If the new version is not marked good, the bootloader reverts by itself. Two versions are kept on disk (2 and 2). (No row-level source. Section sources: Flatcar Container Linux: Upgrade; Bottlerocket: Upgrade; Flatcar Container Linux: Rollback and recovery; Bottlerocket: Rollback and recovery.) Documented
Differs on: what an update writes
Only /usr, on its own partition under dm-verity. The root filesystem holding /etc, /opt and /var is writable and persists.[1] Documented
The whole root filesystem, a read-only dm-verity device. /etc is a tmpfs; persistent state lives on a separate data volume at /local.[2] Documented
So a rollback undoes
The /usr partition. A bad configuration change on the writable root survives an OS rollback.[1]
The root image. Settings sit in an API datastore and are migrated through updates, so they are not part of the image that rolls back. (No row-level source. Section sources: Bottlerocket: Provisioning.)
Neither design is ranked. A smaller unit of reversibility keeps local state; a whole-image unit keeps less drift. Read the matrix column Update unit for every entry.
Looks alike, differs on

Same design lineage and the same A/B /usr layout. They differ on where they are documented to run, so on how an update reaches a node.

Flatcar Container Linux
Azure Container Linux (ACL)
Shared
Microsoft documents ACL as derived from Flatcar Container Linux, and the shipped os-release carries ID_LIKE="flatcar". (No row-level source. Section sources: Azure Container Linux (ACL): OS model.) Both mount /usr read-only under dm-verity and keep /etc writable. Flatcar documents /, /opt and /var as writable too. The ACL documents say only that the ROOT partition persists, and do not list its paths. [1][3] Neither image bundles Kubernetes. Both release amd64 and arm64 images. (No row-level source. Section sources: Flatcar Container Linux: Kubernetes relationship; Azure Container Linux (ACL): Kubernetes relationship; Flatcar Container Linux: Hardware and platform; Azure Container Linux (ACL): Hardware and platform.)
Differs on: where it is documented to run
Bare metal, virtual machines and public clouds. Single-board computers are experimental. (No row-level source. Section sources: Flatcar Container Linux: Hardware and platform.)
AKS, an Azure Marketplace VM image, and QEMU/KVM for development and CI. Bare metal, on-premises and other clouds are not documented. The profile records that as a gap, not as a prohibition. (No row-level source. Section sources: Azure Container Linux (ACL): Hardware and platform.)
So an update reaches a node
The node polls for it and switches its A/B /usr partitions. The update server is self-hostable. (No row-level source. Section sources: Flatcar Container Linux: Upgrade.) On AKS, Microsoft disabled this A/B update in favour of node image replacement, and AKS no longer supports Flatcar for AKS (preview) from 2026-06-08. (No row-level source. Section sources: Flatcar Container Linux: Fleet management.)
On AKS, as a full node image replacement on a weekly cadence, through the NodeImage or None channels only. (No row-level source. Section sources: Azure Container Linux (ACL): Upgrade; Azure Container Linux (ACL): Maturity.) An A/B slot design exists in the repository, and A/B update for UKI images was enabled there on 2026-10-02. No source says that AKS uses it. (No row-level source. Section sources: Azure Container Linux (ACL): Upgrade.)
And a bad update is undone by
The bootloader, by itself, when the new version is not marked successful. (No row-level source. Section sources: Flatcar Container Linux: Rollback and recovery.)
Not determined for a node. The documented reversal is a node-pool reimage to the previous OS SKU. AKS documents that a node image version cannot be downgraded. (No row-level source. Section sources: Azure Container Linux (ACL): Rollback and recovery.)
Neither design is ranked. A node that updates itself keeps the update path with the operator; a node image that the managed service replaces moves the update path, and its timing, to the service. Read the matrix column Update unit for every entry.
Looks alike, differs on

Both run on a base you choose and update from an OCI image. They differ on what the project ships on top of that base.

Kairos
bootc
Shared
Both document running on, or converting, a base distribution that the adopter picks. [4][5] The primary artifact is an OCI image, distributed through a standard registry. (No row-level source. Section sources: Kairos: OS artifact; bootc: OS artifact.) Neither update path requires Kubernetes. (No row-level source. Section sources: Kairos: Upgrade; bootc: Upgrade.)
Differs on: what the project ships
A framework and a distribution. It releases OS images, for the Hadron base only as of v4.3.0. Standard images bundle Kubernetes; core images ship none. (No row-level source. Section sources: Kairos: OS model; Kairos: Kubernetes relationship.)
A mechanism. It ships no OS image. Kubernetes comes with images built on it, such as MicroShift on RHEL image mode. [5](No row-level source. Section sources: bootc: OS model; bootc: Kubernetes relationship.)
So rollback and recovery are
Part of the project: automatic rollback after a failed boot, one attempt on the GRUB path; on Trusted Boot the docs say there is none, while the agent code arms a boot counter of three, a recovery partition and a factory reset. (No row-level source. Section sources: Kairos: Rollback and recovery.)
Shared with the adopting distribution. A manual rollback reorders the existing deployments. Automatic reversion depends on the backend: boot entry counting can be configured on the default OSTree backend and is not configured on the native composefs backend. The docs state no trigger or attempt count. Recovery media and factory reset belong to the distribution. (No row-level source. Section sources: bootc: Rollback and recovery.)
Neither design is ranked. A project that ships the OS also ships its recovery path and its Kubernetes choice; a mechanism leaves those choices, and their upkeep, to whoever builds the image. Read the matrix column Bring your own distro for every entry.
Looks alike, differs on

Both stage a new deployment from an OCI image: Fedora CoreOS always with OSTree, bootc with OSTree by default or with its native composefs backend. They differ on who builds the image, so on who runs the update path.

Fedora CoreOS
bootc
Shared
An update stages a new deployment and leaves the running system unchanged until it is applied. (No row-level source. Section sources: Fedora CoreOS: Upgrade; bootc: Upgrade.) The update payload is an OCI image. (No row-level source. Section sources: Fedora CoreOS: OS artifact; bootc: OS artifact.) /etc and /var are writable, and /etc changes carry forward through a three-way merge. [6,7][8,9,10] Two versions stay on disk. A manual rollback reorders them. (No row-level source. Section sources: Fedora CoreOS: Rollback and recovery; bootc: Rollback and recovery.)
Differs on: who builds the image
Fedora does. You configure the prebuilt image at first boot with Ignition. The project discourages package layering and points heavier customization to Fedora bootc. (No row-level source. Section sources: Fedora CoreOS: Customization.)
You do. Customization is a Containerfile that derives from a base image. The adopter owns the build, test, signing and patching of the result. (No row-level source. Section sources: bootc: Customization.)
So the update path is
Shipped and on by default. An agent polls an update graph with phased rollout, and the graph server is self-hostable. Rollback is manual and needs console access. (No row-level source. Section sources: Fedora CoreOS: Upgrade; Fedora CoreOS: Rollback and recovery.)
The adopter's to assemble: an operator command or a systemd timer, with no phased rollout. Signature checks are policy-based and permissive by default. Automatic reversion depends on the backend, and no trigger is stated. (No row-level source. Section sources: bootc: Upgrade; bootc: Rollback and recovery.)
Neither design is ranked. A prebuilt image comes with the project's update pipeline; a derived image puts its content, and the update pipeline, with the adopter. Read the matrix column Who owns the artifact for every entry.
Looks alike, differs on

Both update atomically and ship no Kubernetes in the image. They differ on what one update is, so on what a rollback can reach.

Fedora CoreOS
openSUSE MicroOS
Shared
Both are general-purpose hosts. Neither ships Kubernetes. (No row-level source. Section sources: Fedora CoreOS: OS model; openSUSE MicroOS: OS model.) The root is read-only, and /var sits outside what an update or a rollback replaces. [6,7][11,12] An update is prepared beside the running system and takes effect on reboot. (No row-level source. Section sources: Fedora CoreOS: Upgrade; openSUSE MicroOS: Upgrade.) Both record a rolling support model with no LTS stream. (No row-level source. Section sources: Fedora CoreOS: Maturity; openSUSE MicroOS: Maturity.)
Differs on: what one update is
A new OSTree deployment, fetched as a GPG-signed OCI image. (No row-level source. Section sources: Fedora CoreOS: Upgrade; Fedora CoreOS: OS artifact.)
A new btrfs snapshot of the root, with package changes applied inside it. /etc is an overlay with a work directory per snapshot. [13](No row-level source. Section sources: openSUSE MicroOS: Immutability.)
So a rollback reaches
The one previous deployment, by hand, with console access. No automatic rollback ships. (No row-level source. Section sources: Fedora CoreOS: Rollback and recovery.)
Any retained snapshot, by command or from the boot menu. health-checker rolls back by itself when boot checks fail. Retention is a snapper policy; its default on MicroOS is not determined. (No row-level source. Section sources: openSUSE MicroOS: Rollback and recovery.)Fact-fix
Neither design is ranked. A fixed pair of deployments keeps one known restore point; a snapshot history keeps as many as its retention policy allows, and each update is assembled from packages on the node. Read the matrix column Automatic rollback for every entry.
Looks alike, differs on

Both are minimal, API-managed images with whole-image A/B updates. They differ on how Kubernetes is tied to the image.

Talos Linux
Bottlerocket
Shared
Neither OS has its own SSH server or shell, and neither installs packages at run time. Operations go through an API. Bottlerocket offers SSH and a shell through an optional admin container. (No row-level source. Section sources: Talos Linux: Operations and debugging; Talos Linux: Customization; Bottlerocket: Operations and debugging; Bottlerocket: Customization.) An update writes a whole image to the inactive partition set, and the previous image stays there. Bottlerocket reverts after a failed boot attempt. Talos reverts only when its init process fails before the node is ready, so a kernel panic before init is not covered. [14,15][16](No row-level source. Section sources: Talos Linux: Rollback and recovery; Bottlerocket: Rollback and recovery.)
Differs on: how Kubernetes is tied to the image
Kubernetes is required and bundled, and the OS manages it. Kubernetes and the OS upgrade separately. (No row-level source. Section sources: Talos Linux: Kubernetes relationship; Talos Linux: Upgrade.)
Each orchestrator variant bundles one agent: a Kubernetes minor version, or ECS. A non-orchestrator variant family also exists, so Kubernetes is optional across the project. The Kubernetes minor is part of the variant name. (No row-level source. Section sources: Bottlerocket: Kubernetes relationship.)
So a move to a new Kubernetes minor is
An upgrade on the same node, independent of the OS version. Talos v1.14 supports five Kubernetes minors. (No row-level source. Section sources: Talos Linux: Kubernetes relationship.)
A variant change, which the docs describe as a node replacement. The updater refuses updates for a different variant. (No row-level source. Section sources: Bottlerocket: Upgrade; Bottlerocket: Kubernetes relationship.)
Neither design is ranked. A Kubernetes version fixed per image keeps the image one unit and makes a Kubernetes upgrade a node replacement; a separate Kubernetes lifecycle keeps the node in place and makes the OS responsible for Kubernetes. Read the matrix column Kubernetes for every entry.
Looks alike, differs on

Both are hyperscaler-owned images with a read-only root and whole-image A/B updates. They differ on where they run, and on how much of the update source and rollback the OS documentation describes.

Container-Optimized OS
Bottlerocket
Shared
A single vendor holds the trademark and is the main sponsor. (No row-level source. Section sources: Container-Optimized OS: Governance; Bottlerocket: Governance.) The root filesystem is read-only, and /etc does not survive a reboot. An update writes the whole root to the passive partition set. COS is also updated by replacing the image. [17][18,19][2][16] Each is the only node image in one mode of its vendor's managed Kubernetes. (No row-level source. Section sources: Container-Optimized OS: Kubernetes relationship; Bottlerocket: Kubernetes relationship.)
Differs on: where it runs
Only on the vendor's cloud: its compute service and its managed Kubernetes. Other clouds, bare metal, on-premises and edge are not supported. (No row-level source. Section sources: Container-Optimized OS: OS model; Container-Optimized OS: Hardware and platform.)
EC2, VMware and local QEMU/KVM. The bare-metal Kubernetes variants are discontinued. (No row-level source. Section sources: Bottlerocket: Hardware and platform.)
And the OS documentation on updates and rollback
Names no update server, says that update payloads are signed and validated but does not describe the scheme, and publishes no rollback procedure. The A/B scheme exists, so rollback reads Unknown, not No. [18]Unknown(No row-level source. Section sources: Container-Optimized OS: Rollback and recovery.)
Describes both. The update repository is self-hostable and checked against TUF metadata. Automatic rollback after a failed boot is documented. (No row-level source. Section sources: Bottlerocket: Upgrade; Bottlerocket: Rollback and recovery.)
Neither design is ranked. A single-cloud scope ties updates and repair to that cloud's managed services; a wider scope needs an update source that works without them. An Unknown in a profile is not a No. Read the matrix column Self-hostable update source for every entry.

Where they came from

Each bar runs from an operating system's first public release to its end, or to today. A tick marks a rename. Lines show forks, named successors, merges, what a system is built on, and influences a project names itself. Select a bar or a line for its source.

Lines appear only where a project, or the project it links to, documents the link. So a project with few lines has none documented yet. Corrections and additions are welcome, with a source: open an issue or send a patch to data/lineage.yaml. See Found a mistake, or something missing?

  • In the matrix
  • Ancestor or relative
  • Fork
  • Named successor
  • Merged into
  • Built on
  • Influence the project names
  • Renamed
  • End not recorded
  • Small text on a bar: who held the project from that date
Where the cloud native operating systems came from, 2009 to 2026A timeline with one bar per operating system. The list after the chart gives the same facts as text, with sources.200920102011201220132014201520162017201820192020202120222023202420252026Chromium OS and CoreOS lineFedora and OSTree lineSUSE and Rancher lineIndependent startsContainer Linux by CoreOS is a fork of Chromium OS (build SDK and update_engine, not the package set).Fedora CoreOS is the named successor of Container Linux by CoreOS.Container Linux by CoreOS merged into Fedora CoreOS.Flatcar Container Linux is a fork of Container Linux by CoreOS, 6 Mar 2018.Flatcar Container Linux calls itself the successor of Container Linux by CoreOS.Red Hat Enterprise Linux CoreOS names Container Linux by CoreOS as an influence.Fedora CoreOS is the named successor of Fedora Atomic Host.Red Hat Enterprise Linux CoreOS is built on Fedora CoreOS.Azure Container Linux is a fork of Flatcar Container Linux.Bottlerocket names Chromium OS as an influence (the boot-partition selection scheme only (Chrome OS-style GPT priority attribute bits)).Container-Optimized OS from Google is a fork of Chromium OS.EVE-OS names Container Linux by CoreOS as an influence (general design, plus partition layout and CoreOS's GRUB patches for A/B rootfs upgrade).EVE-OS names Chromium OS as an influence.c3OS is built on cOS-toolkit, 30 Jul 2021.c3OS is built on Elemental Toolkit, 9 Sep 2022.c3OS names k3OS as an influence, 9 Sep 2022.c3OS names Talos Linux as an influence, 9 Sep 2022.c3OS names Flatcar Container Linux as an influence, 9 Sep 2022.c3OS names Fedora CoreOS as an influence, 9 Sep 2022.Kairos is a fork of Elemental Toolkit (component-level fork of elemental-cli only; not a fork of the OS), 22 Sep 2022.Kairos is built on Hadron Linux, 27 Feb 2026.RancherOS v2 is built on cOS-toolkit, 2021.Elemental (Rancher OS management stack) is built on Elemental Toolkit, 2022.Elemental (Rancher OS management stack) is the named successor of k3OS, 8 Dec 2023.openSUSE Kubic is built on openSUSE MicroOS, Mar 2018.openSUSE MicroOS is the named successor of openSUSE Kubic, 10 Jun 2022.Chromium OSChromium OSContainer-Optimized OS from GoogleOpen the data sheet for Container-Optimized OS from GoogleContainer-Optimized OS from GoogleContainer Linux by CoreOSContainer Linux by CoreOSRed HatFlatcar Container LinuxKinvolkMicrosoftCNCFOpen the data sheet for Flatcar Container LinuxFlatcar Container LinuxAzure Container LinuxOpen the data sheet for Azure Container LinuxAzure Container LinuxFedora Atomic HostFedora Atomic HostFedora CoreOSOpen the data sheet for Fedora CoreOSFedora CoreOSRed Hat Enterprise Linux CoreOSRed Hat Enterprise Linux CoreOSbootcCNCFOpen the data sheet for bootcbootcSUSE MicroOS (OS of SUSE CaaS Platform)SUSE MicroOS (OS of SUSE CaaS Platform)SUSEopenSUSE KubicopenSUSE KubicopenSUSEopenSUSE MicroOSopenSUSEOpen the data sheet for openSUSE MicroOSopenSUSE MicroOSRancherOS (1.x)RancherOS (1.x)RancherRancherOS v2 then Elemental (Rancher OS management stack)SUSESUSEOpen the data sheet for Elemental (Rancher OS management stack)Elemental (Rancher OS management stack) formerly RancherOS v2 2021k3OSk3OSRancherSUSEcOS-toolkit then Elemental ToolkitElemental Toolkit formerly cOS-toolkit 2021SUSESUSEc3OS then KairosSpectro CloudCNCFOpen the data sheet for KairosKairos formerly c3OS 2021Hadron LinuxOpen the data sheet for Hadron LinuxHadron LinuxDianemo then Talos LinuxAndrew RynhardSidero LabsOpen the data sheet for Talos LinuxTalos Linux formerly Dianemo 2018EVE-OSLF EdgeOpen the data sheet for EVE-OSEVE-OSBottlerocketOpen the data sheet for BottlerocketBottlerocketUbuntu CoreOpen the data sheet for Ubuntu CoreUbuntu Core
Every bar and line, as text, with its source
  • Chromium OS and CoreOS line
  • Chromium OS First public 19 Nov 2009 (source code opened)[693]. Held by Google. Chromium OS is built on Gentoo Linux (build system and package management (Portage), not a Gentoo release).[694] Documented
  • Container-Optimized OS from Google First public May 2016 (beta announced in spring 2016; generally available as Container-Optimized OS on 2017-04-05)[352]. Held by Google. Documented Container-Optimized OS from Google is a fork of Chromium OS.[69] Documented
  • Container Linux by CoreOS First public Aug 2013 (first alpha)[695]. Ended 26 May 2020[696]. Created by CoreOS, Inc. Held by Red Hat, Inc from 30 Jan 2018.[697] Documented Container Linux by CoreOS is built on Gentoo Linux.[698] Documented Container Linux by CoreOS is a fork of Chromium OS (build SDK and update_engine, not the package set).[699] Documented Fedora CoreOS is the named successor of Container Linux by CoreOS.[696] Documented Container Linux by CoreOS merged into Fedora CoreOS.[700] Documented Flatcar Container Linux calls itself the successor of Container Linux by CoreOS.[701] Documented
  • Flatcar Container Linux First public 6 Mar 2018 (announced)[518,702]. Created by Kinvolk GmbH from Mar 2018.[518] Documented Held by Microsoft from 29 Apr 2021.[703] Documented Contributed to Cloud Native Computing Foundation (CNCF) from 2 Aug 2024.[704,705] Documented Held by LF Projects, LLC. Flatcar Container Linux is a fork of Container Linux by CoreOS, 6 Mar 2018.[518] Documented
  • Azure Container Linux First public 10 Mar 2026 (announced; generally available 2026-05-29)[261]. Held by Microsoft. Azure Container Linux is a fork of Flatcar Container Linux.[706,20] Documented Azure Container Linux is built on Azure Linux (Azure Linux 3.0 RPM packages).[260] Documented
  • Fedora and OSTree line
  • Fedora Atomic Host First public 9 Dec 2014 (shipped with Fedora 21)[707]. Ended 26 Nov 2019[708]. Fedora Atomic Host is built on Fedora Linux.[707] Documented Fedora Atomic Host is built on Project Atomic.[709] Documented Fedora CoreOS is the named successor of Fedora Atomic Host.[708] Documented
  • Fedora CoreOS First public 20 Jun 2018 (announced)[700,710]. Held by Fedora Project. Held by Red Hat, Inc. Fedora CoreOS is built on Fedora Linux.[710] Documented Fedora CoreOS is built on rpm-ostree.[480] Documented
  • Red Hat Enterprise Linux CoreOS First public 8 May 2018 (announced; first shipped in OpenShift Container Platform 4.1 (2019-06-04))[711]. Held by Red Hat, Inc. Red Hat Enterprise Linux CoreOS names Container Linux by CoreOS as an influence.[711] Documented Red Hat Enterprise Linux CoreOS is built on Fedora CoreOS.[710] Documented Red Hat Enterprise Linux CoreOS is built on Red Hat Enterprise Linux.[711] Documented
  • bootc First public 7 Sep 2023 (first release v0.1)[712]. Held by Red Hat, Inc. Held by Fedora Project. Contributed to Cloud Native Computing Foundation (CNCF) from 21 Jan 2025.[288] Documented bootc is built on OSTree.[293] Documented
  • SUSE and Rancher line
  • SUSE MicroOS (OS of SUSE CaaS Platform) First public Jun 2017 (SUSE CaaS Platform launched 2017-06-20)[713]. End not recorded. Held by SUSE from 2017.
  • openSUSE Kubic First public May 2017 (project started)[714]. Ended 10 Jun 2022[715]. Held by openSUSE Project from May 2017. openSUSE Kubic is built on openSUSE MicroOS, Mar 2018.[716] Documented openSUSE MicroOS is the named successor of openSUSE Kubic, 10 Jun 2022.[715] Documented
  • openSUSE MicroOS First public 22 Mar 2018 (as MicroOS, base of Tumbleweed Kubic)[716]. End not recorded. Held by openSUSE Project from 2017. openSUSE MicroOS is built on openSUSE Tumbleweed, 2018.[716] Documented
  • RancherOS (1.x) First public 9 Feb 2015 (first release v0.0.2 on 2015-02-09; repository created 2015-01-05)[717]. Last release 5 Feb 2021; the project says it is no longer maintained[718,719]. Created by Rancher Labs from 5 Jan 2015. Held by SUSE from 1 Dec 2020.[720] Documented
  • RancherOS v2 First public Jun 2021 (first commit). Ended Nov 2022. Held by SUSE from 6 Jun 2021. RancherOS v2 is built on cOS-toolkit, 2021.[721] Documented RancherOS v2 was renamed Elemental (Rancher OS management stack), 19 Jan 2022.[722] Inferred
  • Elemental (Rancher OS management stack) First public Apr 2022 (first release v0.1.0 on 2022-04-21; repository created 2022-01-19). Held by SUSE from 19 Jan 2022. Elemental (Rancher OS management stack) is built on Elemental Toolkit, 2022.[723] Documented Elemental (Rancher OS management stack) is built on SUSE Linux Micro.[402] Documented
  • k3OS First public 16 Apr 2019 (first release v0.1.0 on 2019-04-16; repository created 2019-03-06)[724]. Last release 9 Oct 2021; the project says it is no longer maintained[725,726]. Created by Rancher Labs from 6 Mar 2019. Held by SUSE from 1 Dec 2020.[720] Documented Elemental (Rancher OS management stack) is the named successor of k3OS, 8 Dec 2023.[727] Documented k3OS is built on Alpine Linux, 2019.[728] Documented k3OS names LinuxKit as an influence, 2019.[728] Documented
  • cOS-toolkit First public Jan 2021 (repository created)[729]. Ended 1 Jun 2022[730]. Held by SUSE from 8 Jan 2021. cOS-toolkit was renamed Elemental Toolkit, 1 Jun 2022.[730] Documented
  • Elemental Toolkit First public Jun 2022 (renamed from cOS toolkit)[730]. Held by SUSE from 1 Jun 2022.
  • c3OS First public Jul 2021[731]. Ended Sep 2022[732]. Created by Ettore Di Giacinto from 30 Jul 2021. c3OS was renamed Kairos, 15 Sep 2022.[732,733] Documented c3OS is built on cOS-toolkit, 30 Jul 2021.[734] Documented c3OS is built on Elemental Toolkit, 9 Sep 2022.[735] Documented c3OS is built on openSUSE Leap, 30 Jul 2021.[736] Documented c3OS names k3OS as an influence, 9 Sep 2022.[735] Documented c3OS names Talos Linux as an influence, 9 Sep 2022.[735] Documented c3OS names Flatcar Container Linux as an influence, 9 Sep 2022.[735] Documented c3OS names Fedora CoreOS as an influence, 9 Sep 2022.[737] Documented
  • Kairos First public Sep 2022 (as Kairos; version 1.0 announced 2022-09-29)[738,739]. Created by Ettore Di Giacinto from 30 Jul 2021. Sponsored by Spectro Cloud from 29 Sep 2022.[739] Documented Contributed to Cloud Native Computing Foundation (CNCF) from 13 Apr 2024.[551] Documented Kairos is a fork of Elemental Toolkit (component-level fork of elemental-cli only; not a fork of the OS), 22 Sep 2022.[740,741] Documented Kairos is built on Hadron Linux, 27 Feb 2026.[742] Documented
  • Hadron Linux First public Nov 2025 (first alpha release 2025-11-28; announced 2025-12-17)[743,744]. Created by Kairos project from 28 Jun 2025.[744] Documented Sponsored by Spectro Cloud.[745] Documented
  • Independent starts
  • Dianemo First public 3 Apr 2018 (first alpha release v0.1.0-alpha.0)[746]. Ended 15 Nov 2018[747]. Created by Andrew Rynhard from 3 Nov 2017. Dianemo was renamed Talos Linux, 15 Nov 2018.[747] Documented
  • Talos Linux First public 3 Apr 2018 (as Dianemo; first stable release 1.0 on 2022-03-29)[746]. Held by Talos Systems, Inc. (renamed Sidero Labs 2021-10-04). Held by Sidero Labs from 4 Oct 2021.[748] Documented
  • EVE-OS First public Jan 2019 (announced as an LF Edge project contributed by ZEDEDA; seed code handover announced 2019-05-14)[749]. Created by ZEDEDA.[749] Documented Contributed to LF Edge (The Linux Foundation) from 24 Jan 2019.[750] Documented EVE-OS is built on Alpine Linux (userland environment in the root filesystem).[411] Documented EVE-OS is built on LinuxKit (build toolkit and init system).[411] Documented EVE-OS names Container Linux by CoreOS as an influence (general design, plus partition layout and CoreOS's GRUB patches for A/B rootfs upgrade).[411,411] Documented EVE-OS names Chromium OS as an influence.[411] Documented EVE-OS names Qubes OS as an influence.[411] Documented EVE-OS names SmartOS as an influence.[411] Documented
  • Bottlerocket First public Mar 2020 (public preview announced; generally available 2020-08-31)[751]. Created by Amazon Web Services. Documented Bottlerocket is built on Amazon Linux 2023 (kernel and GRUB source RPMs only; not the userland or the image).[752] Documented Bottlerocket names Chromium OS as an influence (the boot-partition selection scheme only (Chrome OS-style GPT priority attribute bits)).[753] Documented
  • Ubuntu Core First public Dec 2014 (announced 2014-12-09; first stable version shipped in Ubuntu 15.04 (2015-04-21))[754]. Held by Canonical. Documented Ubuntu Core is built on Ubuntu (LTS releases).[240,755] Documented Ubuntu Core names Ubuntu phone (Ubuntu Touch, Canonical era) as an influence (update and confinement technology (snappy) came from the phone work).[754] Documented

Alternative paradigms

Worth mentioning

Considered and excluded

Who is behind it

I am Mauro Morales, the person behind the cloud native OS Pulse. I work as a Staff Engineer at Spectro Cloud, and I am one of the maintainers of Kairos and Hadron, two of the entries. I have also done quite a lot of public speaking promoting these projects. So I cannot claim to be completely unbiased.

I put this project together wearing my CNCF Ambassador hat. To keep my bias in check, I tried to guide the agents toward a fair design by putting these sentences in the prompt:

Do not construct criteria specifically to make Kairos look good.
If the comparison appears overwhelmingly favorable to Kairos, challenge the methodology before publishing it.

A prompt is not a guarantee, so the controls are in the method: a dated source and an evidence label on every claim, a separate fact-check per profile, maintainers who will be invited to check their own profile, and fixes open to anyone. How it was made describes each step. None of this removes my bias. It makes it easier for you to find.

How it was made

Method, stake, and how to correct the record.

AI agents did most of the reading, the bookkeeping and the first drafts of this Pulse. You do not have to trust them, or me. Every documented claim names its source, with the date it was read and a label that says how strong the evidence is. Check any claim against its source. If it does not hold, the Pulse is wrong, and I want to know.

That is my case for using AI here. The Pulse is not opinion. It records what each project's own docs, code, release notes and announcements say. Machines read and cite well. They also get things wrong.

My role

I drove the Pulse. I did not validate every claim myself. I read each profile with my own Kairos experience and questioned what did not make sense. For the rest I relied on independent agent reviewers and fact-checkers. I do not own each project's results. The sources do, and so do the people who know those projects better than I do.

The process

  1. Method first. I told the agent to challenge this project list and taxonomy before any research. It did. One label per project mixed three separate questions, so the Pulse uses three axes. Fedora CoreOS and bootc got separate profiles, because a distribution and a mechanism are not peers. The agent also found that my list left out openSUSE MicroOS and Ubuntu Core. Both compete directly with Kairos, so the gap flattered Kairos. I had them added.
  2. Schema and validator. Fourteen dimensions, closed vocabularies, one evidence label per dimension, and a dated source for every documented claim. The validator rejects a profile that claims an absence without a source, infers without naming its evidence, marks something unknown without saying where it looked, lists no costs for a design, or carries a score or rank field.
  3. Profiles. Sixteen profiles from primary sources: eleven in the matrix, plus Hadron Linux, NixOS, openSUSE MicroOS, Unikraft and Yocto Project. Collected: eleven on 15 September, Hadron Linux on 22 September, Azure Container Linux (ACL) and EVE-OS on 5 October, Yocto Project on 12 October, and Elemental on 14 October. Marketing comparison pages were not accepted as a source for anything.
  4. Re-verification. On 22 September the agents re-read every cited source and checked every quote against the live page. Each profile got its own fact-check pass, which also asked whether it was treated more softly or more harshly than Kairos. Hadron was added. My brief called Hadron an immutable OS positioned like Flatcar. Its own documentation says otherwise, so the profile says otherwise.
  5. Rollback deep dives. Six systems (Kairos, bootc, Fedora CoreOS, Flatcar, Bottlerocket, NixOS) were booted in VMs, moved to a second version and rolled back, to see what state survives. Where a step was not run as a real upgrade, the deep dive says INFERRED or NOT TESTED.
  6. Second review. On 5 October three independent fact-check agents re-read the claims against the live sources, split by project, and another agent reviewed whether these are the right comparison points. Six claims about other projects were corrected (see What went wrong). Base Azure Linux left the dataset, because it is not immutable, and Azure Container Linux replaced it. Corrections now total 303, 52 of them on Kairos.
  7. Maintainer review. Not done yet. Each project will get its profile and its open questions, with one ask: check the facts. It is not a request to endorse the analysis.

Tools and models

The agents were Anthropic's Claude models, running in Claude Code. Each task had a written brief, its own agent session, its own branch and its own pull request. I merged every change. For this first version, Anthropic provided the model access, through its Claude for Open Source program. Anthropic had no say in the content.

Claude Opus 5 wrote the method, the first ten profiles and the first article draft. Claude Sonnet 5 did the rest: the two added profiles, the re-verification, Hadron and the rollback experiments. Two of those briefs asked for a stronger model than the one that ran. The rollback experiments and the re-verification both ran on Sonnet 5. After the first version, Claude Sonnet 5.5 made all but three of the commits: the Elemental profile, the fleet reading of the criteria, the provisioning criterion, the Kubernetes distribution filter, the data corrections, the site changes and the cleanup of the research files. A second pass on Claude Opus checked the Elemental profile against its sources. Claude Opus 5.5 made the other three: the brand mark and the publishing setup. Since the first public version, every commit other than a merge names the assisting model in a Co-developed-by: trailer, and that history is public in the Pulse repository. The history before the first public version is not public. It came in as one commit, and the trailer on that commit names only the model that made the import. Commits from the mauro-agent account were made by an AI agent that I operate. I am the person behind that account and I answer for its work. The task briefs are kept. The exact prompts each session received are not, and neither is which model ran each fact-check pass.

What went wrong

  • An early summary overstated a Secure Boot finding about Kairos. It mixed up two boot paths. I caught it, and the source code settled it.
  • An early pass rated Kairos rollback weaker than its peers. Part of that was a counting error: the same A/B design got different "retained versions" numbers in different profiles. The fix favoured Kairos, a project I help maintain. So I want it on the record that the code and the docs decided it, not me. Both are cited.
  • Some absence claims about other projects rested only on missing documentation. They were downgraded to unknown. One claim was simply wrong: Unikraft does have a governance document and maintainer lists.
  • The second review found six claims about other projects that were wrong in a way that made them look worse. They were fixed before publication.

If the cloud native OS Pulse helps you, please star it on GitHub. It helps more people find it.

Why it exists

Back in 2023 I joined the Kairos team. At the time I had never heard of immutable operating systems, so I was eager to learn. Beyond the documentation of each project, I could not find many sources. I wanted a bird's-eye view, one that would show me the patterns and not only how each project does things on its own. The first post I read was my colleague Nicolas Vermande's k3OS Alternatives: Top Container OS for Edge Kubernetes on the Spectro Cloud blog. It is a great read if you already know the projects it mentions, but it assumes you do. And if you are reading it today, it has aged.

Another good source I found was the CNCF Special Purpose Operating System Working Group, under what was then TAG Runtime. I joined, and I had a great time learning about the different projects. We even put together a couple of panels: one at KubeCon, and one at Open Source Summit Europe in Vienna. We also met as a birds-of-a-feather group at FOSDEM for three years in a row (2024, 2025, 2026). When the CNCF restructured its TAGs, the group was closed, and since then I have been looking for ways to keep its spirit alive. Still, none of this gave a newcomer the overview I had wanted back in 2023.

My first attempt at that overview was a talk at Cloud Native Days Italy in May 2026, What Should a Cloud Native OS Look Like?. I realized a talk does not have enough time to cover so many projects in enough detail. It is also much harder not to be biased when speaking in person. In a written document, every claim can link to its source, and separate agents can check each claim against that source. That makes it easier to try to stay objective.

The closest thing I found to a field-wide view is the kube.today survey, Immutable OS for Kubernetes: Where Theory Meets Operations, with answers from 2,138 practitioners. It was sponsored by Spectro Cloud, my employer, and its disclosure says the sponsor had no input on the questions or the analysis. I think it is of great value, because it shows what people actually do. But it does not help much if you are not sure how to compare these projects, or where to start. That is the gap the cloud native OS Pulse tries to close. It is not about sentiment. It records what each project documents and ships, with a source and an evidence label on every cell, plus a few rollback experiments run in VMs.

It is not a scorecard, and it does not pick a winner. My hope is that you find in it a clear view of what image-based, immutable systems buy you and what they cost, which options are out there, and enough perspective to make an informed choice of your own.

The Pulse is a rolling release. The header of every page shows the commit and the date it was built from. When a project ships a newer release than the one profiled, its entry carries a badge that says so until I re-validate it. If you spot something wrong, please open a pull request against that profile, or open an issue. Anyone can.

What I'd like to see

Everything else on this page tries to be neutral. This section does not. It collects what I would like cloud native operating systems to accomplish, as a group, over the next few years. You should know where I stand: I am one of the Kairos maintainers and I work for Spectro Cloud, so read this with that in mind. These are wishes for the whole field, not a description of any one project. Nothing here is used to rank the entries, and no project has to agree with it.

Reconcile the OS the way Kubernetes reconciles an app

When you deploy an app on Kubernetes, you declare what you want and a controller keeps it that way. If a pod dies, it gets replaced, and a new replica gets the same spec. The OS is often handled differently. In many setups an upgrade is something you trigger, and it runs once. Some tools do keep nodes up to date on their own, but they often follow the latest release on a channel, not a version you declared next to your apps. Whether a node that joins later, or one that rolled back, ends up on the version you wanted depends on the tool you picked.

I would like the OS to be part of the same loop as the apps. You declare the OS version a group of nodes should run, and something keeps them there. Then, when an app needs a newer kernel or a new driver, you could ship the OS change and the app change together, and the cluster would converge on both, OS first. That would close much of the gap between the OS and the platform on top of it. Some projects already get part of the way there, inside Kubernetes or outside it. The matrix shows what each one does today.

Is your project here?

If you work on one of the projects in the Pulse, I would like your help. Every project gets the same request: check that your project is represented correctly and fairly. It usually takes about fifteen minutes, and saying no is fine. If nobody from a project wants to look after its profile, an outside person may do it, under the rules in GOVERNANCE.md in the repository. You can take it over at any time.

That is the whole request. It is not a request to endorse the Pulse, to agree with how it is organised, or to review any other project. Correcting a fact about your project does not mean you agree with anything else here, and I will never present it as agreement.

What to check

  • Your project's data sheet: click its name in the Matrix. It lists every value from the matrix in full, with its evidence and sources.
  • Your row in the Comparison matrix. Each cell shows a short value with its evidence label. Your data sheet has the full text behind every cell.
  • Your project's profile in the repository. Every claim carries an evidence label and a source, so you can see where each one came from.
  • The open questions in your profile. These are the things I could not settle from public sources, and they are where your help counts most.

How to send a correction

The repository is public at cloudnativeos-org/pulse. Open an issue with the correction form or send a pull request against your project's profile with a primary source for the correct value. You can also send me the correction with a source through the contact links on mauromorales.com. Every correction is recorded in the profile with its date and its source, so the history stays visible in the data. If you disagree with a claim the sources support, I record your view next to it rather than hide it. See Found a mistake, or something missing? for the links.

The same request goes to every project in the Pulse, including Kairos and Hadron. I am one of the maintainers of both, and I work for Spectro Cloud, so changes to those two profiles follow the conflict-of-interest rules in GOVERNANCE.md in the repository. They go through a public pull request that stays open for at least seven days, and once the Pulse has a maintainer with no tie to Kairos, Hadron or Spectro Cloud, that person approves the changes I make to them. A fact check by a maintainer of Kairos or Hadron is welcome. It is a fact check, not that approval.

Beyond a review

If you like the format and the method, I would welcome turning the Pulse into a group effort: a comparison kept up by people from several of these projects, not by me alone. Tell me if that interests you.

Glossary

General-purpose OS
An operating system built to run anything, such as Ubuntu, Debian or Fedora. It is installed once and then maintained by changing it in place for the rest of its life.
cloud native OS
In the Pulse, an OS that meets the five inclusion criteria across a fleet, not on a single node: atomic updates (versioned OS), immutable at runtime (read-only OS files), rollback (to a version), config-driven provisioning, and Kubernetes ready.
In-place upgrade
An upgrade that changes the running system piece by piece, for example package by package. The result depends on the state the machine was in before.
Atomic upgrade
An upgrade that applies the new version as a whole or not at all. If it fails, the old version is still intact. Atomic alone does not meet the first criterion: the version must also be one artifact, built once, that every node in a fleet runs.
Image-based
The OS is built ahead of time as one complete image, and that image is what gets installed and updated.
OCI image
A container image in the format the Open Container Initiative specifies. It is stored in a container registry and pulled from it. Some projects ship the OS itself as an OCI image.
OSTree
A system for storing and deploying complete, versioned filesystem trees of an OS. Each deployment is one tree, and the bootloader chooses which deployment boots.
composefs
A Linux mechanism that mounts a read-only filesystem image whose file contents sit in a shared, content-addressed store. With fs-verity, the kernel can check that the contents match what the image records.
A/B partitions
Two copies of the OS on disk. An update writes the copy that is not running, and the machine switches to it at the next boot.
Version
One build of the OS, identical on every machine that runs it.
Snapshot
A point-in-time copy of a filesystem on one machine, for example with btrfs. It captures that machine's state, so it is unique to that machine. A version is the same everywhere; a snapshot is not.
Rollback
Going back to the previous OS version, the one the whole fleet ran, after an update. Each node keeps that version locally, ready to boot. An automatic rollback happens without a person, when the new version fails a check at boot.
Immutable
Part of the OS is read-only on a running machine, and changes to that part arrive only through an update. Which part varies by system: the whole root filesystem on some, only /usr on others, and some keep /etc or a data volume writable. Writable does not always mean persistent: some paths are writable through a temporary overlay or an in-memory filesystem, and changes there are lost at the next boot. The matrix shows what each entry protects.
Drift
Machines that should be the same become different over time, through changes that were not planned or not recorded.
Day 0, day 2
Day 0 is when a node is first set up. Day 2 is everything after that: upgrades, fixes, changes, decommissioning.
Config-driven provisioning
A node sets itself up from a written config when it is installed or first boots, with no interactive install. Some projects apply the config again at every boot, on demand, or by reconcile. The config can be one file or several. Also called declarative provisioning. Both a configuration management tool and config-driven provisioning can configure a running node. A configuration management tool also changes the OS itself, such as packages and system files. Config-driven provisioning sets the node's settings. On some projects, it can also write files or run commands in the writable parts. The OS image changes only with a new version. On some projects, provisioning can also run before the OS starts.
Configuration management
Tools such as Ansible, Puppet or Chef that apply changes to machines to bring them toward a described state. Puppet is declarative, while Ansible and Chef run steps in order. See also config-driven provisioning.
Cluster API
A Kubernetes project that creates, upgrades and deletes Kubernetes clusters through declarative Kubernetes resources. Providers adapt it to an infrastructure, a bootstrap method or a control plane.
One-shot run
A fleet upgrade that runs once when someone or something triggers it, and then stops. A node that joins later, or changes afterwards, stays where it is until the next run.
Reconciled in place
A controller keeps comparing the declared OS version with each node, and upgrades the existing node whenever the two differ.
Reconciled by replacement
A controller keeps comparing the declared OS version with each node, and replaces a node that differs with a new node built from the declared version.
Pets and cattle
Pets are machines cared for one by one. Cattle are machines that are interchangeable and replaced rather than repaired.
Twelve-factor app
A set of practices for building applications that are stateless, disposable and easy to scale. See 12factor.net.
Boot trust chain
How far trust reaches when a machine starts. With no Secure Boot, nothing is checked. With Secure Boot, the firmware checks the first boot component. With measured boot, each stage records what it loaded in the TPM. The chain reaches the running system only when the final root filesystem is covered by what was signed: either the whole OS is inside the signed image, or the root hash sits in a signed boot artifact. The matrix column numbers these steps from level 0 (nothing checked) to level 3 (running root covered).
Secure Boot
A UEFI firmware feature: before running the first boot component, the firmware checks its signature against keys stored in the firmware.
Measured boot
Each boot stage records a hash of what it loads into the TPM. The record can be used to release a secret only to a known boot state, or to prove that state to someone else.
TPM
Trusted Platform Module: a chip, or a virtual one in a cloud VM, that holds the boot measurements and can keep keys sealed to them.
Remote attestation
A report of a machine's boot measurements, signed by its TPM and checked by another system before it trusts the machine.
UKI
Unified Kernel Image: the kernel, its initrd and its command line in one signed boot file. See the UAPI Group specification. After early boot, the system usually pivots to a root filesystem outside the UKI.
Pivot
The point where early boot hands over from the initrd to the real root filesystem (switch_root). If that root filesystem is not covered by what was signed and measured, the chain of trust stops at the pivot.
USI
Unified System Image: "full OS images packed in a UKI", in Daan De Meyer's words. The whole OS is inside the signed image, so there is no separate root filesystem to pivot to.
dm-verity
A Linux kernel feature that checks every block of a read-only filesystem against a hash tree. When the root hash is part of the signed and measured boot image, the chain of trust extends to that filesystem.
TUF
The Update Framework: a specification for securing software update systems. Signed metadata, split across several roles that each have their own keys, tells a client which files are current and what their hashes must be. See theupdateframework.io.
SBOM
Software Bill of Materials: a machine-readable list of the components, and their versions, in a piece of software. Common formats are SPDX and CycloneDX.
FIPS
Federal Information Processing Standards, published by the US government. Here it means FIPS 140, which sets requirements for cryptographic modules. A FIPS build uses cryptographic modules validated against it.
LTS
Long-term support: a release line that gets fixes for a longer, stated period than regular releases.
Framework or mechanism
A tool that builds or manages OS images rather than being one OS itself, such as Kairos or bootc. It meets the Kubernetes rule through the images built with it.
System extension (sysext)
A systemd feature that overlays extra files onto /usr and /opt from a separate image, without changing the base image. It adds software to an OS whose /usr is read-only.
Evidence label
How each claim in the Pulse is backed. Documented: Explicitly stated by a primary source. At least one source URL. Inferred: A reasonable conclusion from evidence that does not state it outright. Names its evidence. Unknown: Not enough evidence. Says where we looked. Not tested: Needs an experiment this edition does not run.
Entry kind
What sort of object an entry is. An entry can carry more than one. distribution: ships released OS artifacts with versions and a release process. platform-os: an OS produced mainly to run one vendor platform. framework: a toolchain for producing an OS; the adopter owns the result. mechanism: a component that implements part of the lifecycle; not an OS on its own. build-system: builds an OS image from source recipes; the adopter owns the image, and each capability comes from the layers the adopter selects.

What the columns mean

Each column of the comparison matrix, with the question it answers. In the matrix, the ? next to a column title opens the same text.

Entry
The entry, the version observed and its release date, and the entry kind. Click the name to open the entry's data sheet, with every column in full. Glossary: Entry kind.
Who owns the artifact
Who builds and patches what you run. Glossary: Framework or mechanism.
Bring your own distro
Can the entry run on a base distribution you choose?
Day-0 paths
How a node gets its first install and bootstrap. The data sheet names the configuration it reads. Glossary: Day 0.
Configuration tool
The config-driven provisioning tool, with four facts: the earliest point it runs, the latest, how it repeats and what it can change. The data sheet gives its license and what disk work it can do early. Both a configuration management tool and config-driven provisioning can configure a running node. A configuration management tool also changes the OS itself, such as packages and system files. Config-driven provisioning sets the node's settings. On some projects, it can also write files or run commands in the writable parts. The OS image changes only with a new version. On some projects, provisioning can also run before the OS starts. Glossary: Config-driven provisioning.
Update unit
What one update replaces. The data sheet names the mechanism and the longest hold. Glossary: Image-based, A/B partitions.
Adding software to the OS
How an adopter adds software to the OS itself. This means host-level software, not workloads. One tag per documented way. systemd-sysext: System extension images, merged over /usr. Vendor extensions: A project-specific extension format, such as Talos system extensions. Derive the image: Build a new OS image from the project's image, for example a Containerfile that starts FROM it. Package layering: Install packages onto the image-based system, for example rpm-ostree install. Transactional packages: Install packages into a new snapshot, for example transactional-update pkg install. Snaps: Snap packages. Build-time only: The image is composed at build and nothing is added after. Not supported: The project states you cannot add software to the host. Unknown: nothing was found. Kairos and bootc build from a base distribution. Their own documented way is Derive the image. The base distribution's package manager is not credited after install unless their own documentation says so. The data sheet gives each way with how it is done and its sources. Glossary: System extension (sysext), Image-based.
Update signature check
Can a node check that an update is signed? A cell shows how far the entry can get. Opt-in marks a check the adopter has to turn on, with the mode or setting that turns it on. The data sheet says whether the check is optional or on by default, what it checks, and where the default leaves you.
Boot trust chain
How far trust reaches at boot: level 1 Secure Boot, level 2 measured boot, level 3 the running root is covered by the signature. A cell shows the highest level the entry can reach. Opt-in marks a level the adopter has to turn on, with the mode that reaches it. The data sheet says whether it is optional or on by default, how far it goes, and where the default leaves you. Writable state such as /etc and /var is outside the signature on every entry. Glossary: Boot trust chain, UKI, Pivot, dm-verity.
Automatic rollback
The machine reverts to the previous version by itself when the new one fails to boot. Glossary: Rollback.
Fleet upgrade paths
Documented ways a fleet gets its OS upgraded beyond one command per node, each with its reconciliation model: a one-shot run, reconciled in place, or reconciled by replacement. The data sheet names each tool and its license. Glossary: One-shot run, Reconciled in place, Reconciled by replacement.
Kubernetes
Whether Kubernetes is required, optional or not bundled, then each documented way to run it: distributions such as k3s or MicroK8s, and install tools such as kubeadm or Cluster API. Each distribution shows how the project offers it: in the image, set up by the OS, as a build option, or as an add-on.
Node access
How you reach a node. API-only access limits changes to what the API exposes and makes them easy to log; a shell is more flexible and familiar. Neither is more secure by default.
Cluster API
How a node joins a cluster through Cluster API. Glossary: Cluster API.
AI accelerators
Accelerators the project or its vendor documents. The data sheet says how the driver reaches the node, whether its modules load with Secure Boot, and the NVIDIA GPU Operator mode. NVIDIA's own validated list names none of these entries; it documents Container-Optimized OS on GKE, and lists Jetson as not supported. An entry that builds the OS from a base distribution you pick is credited with what that base distribution documents, once, as "Via your base distribution". Picking a specific accelerator in the filter keeps those entries too, marked.
Architectures
CPU architectures that have released images, not intentions, each tagged. An entry that builds the OS from a base distribution you pick also lists the architectures its own components are built for, as "via your base distribution". Picking an architecture in the filter keeps those entries too, marked.
Self-hostable update source
Can you host where a node downloads its OS updates from, for example for an air-gapped site? Tools that decide when a node upgrades, such as Omni or the AuroraBoot fleet server, are a different question.
Who holds the assets
Who holds the trademark and the project assets.
Support model
The support model. The data sheet says whether commercial support exists. Glossary: LTS.
Mounts
What is read-only, what is writable but reset on reboot, what persists, and whether the adopter can change that. Data sheet only: the matrix has no Mounts column.

The fourteen dimensions

The fourteen dimensions every profile records. There is no section per dimension yet; the values are in each project's profile and in the data sheets.

  1. OS model
  2. Immutability
  3. OS artifact
  4. Upgrade
  5. Rollback and recovery
  6. Customization
  7. Kubernetes relationship
  8. Hardware and platform
  9. Provisioning
  10. Security
  11. Operations and debugging
  12. Fleet management
  13. Governance
  14. Maturity

Sources

Primary sources only. Each was read on the date shown.

  1. Flatcar disk partitions: read-only /usr, stateful / Flatcar Container Linux. official-docs. Retrieved 12 Oct 2026.https://www.flatcar.org/docs/latest/devguide/sdk-disk-partitions/
  2. Bottlerocket security guidance: system mounts Bottlerocket. source-repo. Retrieved 12 Oct 2026.https://github.com/bottlerocket-os/bottlerocket/blob/8db07cb/SECURITY_GUIDANCE.md
  3. Azure Container Linux architecture: the /usr partition Azure Container Linux (ACL). source-repo. Retrieved 12 Oct 2026.https://github.com/microsoft/azure-container-linux/blob/4dd4f8b/acl/docs/architecture.md
  4. kairos.io/docs/architecture/meta/ Kairos. official-docs. Retrieved 22 Sep 2026.https://kairos.io/docs/architecture/meta/
  5. github.com/bootc-dev/bootc/blob/main/ADOPTERS.md bootc. source-repo. Retrieved 22 Sep 2026.https://github.com/bootc-dev/bootc/blob/main/ADOPTERS.md
  6. Fedora CoreOS storage: immutable root Fedora CoreOS. official-docs. Retrieved 12 Oct 2026.https://docs.fedoraproject.org/en-US/fedora-coreos/storage/
  7. Fedora Change: composefs by default for CoreOS and IoT (targeted release Fedora Linux 41) Fedora CoreOS. design-doc. Retrieved 19 Oct 2026.https://fedoraproject.org/wiki/Changes/ComposefsAtomicCoreOSIoT
  8. bootc filesystem: read-only root bootc. official-docs. Retrieved 12 Oct 2026.https://bootc.dev/bootc/bootc-filesystem.7.html
  9. bootc security: fs-verity by backend bootc. official-docs. Retrieved 19 Oct 2026.https://bootc.dev/bootc/bootc-security.7.html
  10. bootc composefs backend: two storage backends bootc. official-docs. Retrieved 19 Oct 2026.https://bootc.dev/bootc/bootc-composefs.7.html
  11. openSUSE-MicroOS image definition (kiwi), openSUSE:Factory, revision 103: separate subvolumes openSUSE MicroOS. source-repo. Retrieved 12 Oct 2026.https://api.opensuse.org/public/source/openSUSE:Factory/openSUSE-MicroOS/openSUSE-MicroOS.kiwi?rev=103
  12. transactional-update guide: /var openSUSE MicroOS. official-docs. Retrieved 12 Oct 2026.https://kubic.opensuse.org/documentation/transactional-update-guide/tu-setup.html
  13. openSUSE transactional-update documentation, /etc openSUSE MicroOS. source-repo. Retrieved 6 Oct 2026.https://github.com/openSUSE/transactional-update/blob/ef8af9f/doc/transactional-update.xml
  14. Upgrading Talos Talos Linux. official-docs. Retrieved 6 Oct 2026.https://docs.siderolabs.com/talos/v1.14/configure-your-talos-cluster/lifecycle-management/upgrading-talos
  15. Talos bootloader Talos Linux. official-docs. Retrieved 6 Oct 2026.https://docs.siderolabs.com/talos/v1.14/platform-specific-installations/bare-metal-platforms/bootloader
  16. Bottlerocket signpost README, partition sets Bottlerocket. source-repo. Retrieved 6 Oct 2026.https://github.com/bottlerocket-os/bottlerocket-core-kit/blob/develop/sources/updater/signpost/README.md
  17. COS disks and file system: stateless partitions Container-Optimized OS. official-docs. Retrieved 12 Oct 2026.https://docs.cloud.google.com/container-optimized-os/docs/concepts/disks-and-filesystem
  18. Container-Optimized OS auto update Container-Optimized OS. vendor-docs. Retrieved 6 Oct 2026.https://docs.cloud.google.com/container-optimized-os/docs/concepts/auto-update
  19. GKE node pool upgrade strategies (surge, blue-green) Container-Optimized OS. vendor-docs. Retrieved 6 Oct 2026.https://docs.cloud.google.com/kubernetes-engine/docs/concepts/node-pool-upgrade-strategies
  20. learn.microsoft.com/en-us/azure/azure-linux/azure-container-linux-overview Azure Container Linux (ACL). vendor-docs. Retrieved 22 Sep 2026.https://learn.microsoft.com/en-us/azure/azure-linux/azure-container-linux-overview
  21. docs.cloud.google.com/container-optimized-os/docs/resources/sources Container-Optimized OS. official-docs. Retrieved 22 Sep 2026.https://docs.cloud.google.com/container-optimized-os/docs/resources/sources
  22. https://documentation.ubuntu.com/core/reference/release-notes/ Ubuntu Core. vendor-docs. Retrieved 22 Sep 2026.https://documentation.ubuntu.com/core/reference/release-notes/
  23. microsoft/azure-container-linux README, license Azure Container Linux (ACL). governance-doc. Retrieved 5 Oct 2026.https://github.com/microsoft/azure-container-linux/blob/aclmain/README.md
  24. Azure Container Linux (ACL) Azure Container Linux (ACL). announcement. Retrieved 5 Oct 2026.https://github.com/Azure/AKS/issues/5649
  25. CNCF project page, bootc bootc. foundation-page. Retrieved 22 Sep 2026.https://www.cncf.io/projects/bootc/
  26. Relationship to other projects bootc. official-docs. Retrieved 19 Oct 2026.https://github.com/bootc-dev/bootc/blob/main/docs/src/bootc-relationships.7.md
  27. General availability Container-Optimized OS. announcement. Retrieved 22 Sep 2026.https://cloud.google.com/blog/products/gcp/container-optimized-os-from-google-is-generally-available/
  28. Rancher Guide (Elemental), SUSE documentation Elemental. vendor-docs. Retrieved 14 Oct 2026.https://documentation.suse.com/smart/rancher/html/Rancher-OS/index.html
  29. lf-edge/eve docs/README.md EVE-OS. official-docs. Retrieved 5 Oct 2026.https://github.com/lf-edge/eve/blob/master/docs/README.md
  30. Fedora Change: move updates from OSTree to OCI Fedora CoreOS. design-doc. Retrieved 22 Sep 2026.https://fedoraproject.org/wiki/Changes/CoreOSOstree2OCIUpdates
  31. Announcing the Flatcar Linux project Flatcar Container Linux. announcement. Retrieved 22 Sep 2026.https://www.flatcar.org/blog/2018/03/announcing-the-flatcar-linux-project/
  32. CNCF project page, Kairos Kairos. foundation-page. Retrieved 22 Sep 2026.https://www.cncf.io/projects/kairos/
  33. Releasing the Chromium OS open source project Chromium OS. Official Google Blog. Retrieved 6 Oct 2026.https://googleblog.blogspot.com/2009/11/releasing-chromium-os-open-source.html
  34. Portage / ebuild FAQ Chromium OS. The Chromium Projects. Retrieved 6 Oct 2026.https://www.chromium.org/chromium-os/developer-library/guides/portage/ebuild-faq/
  35. CoreOS stable release Container Linux by CoreOS. CoreOS, Inc.. Retrieved 6 Oct 2026.https://coreos.com/blog/stable-release.html
  36. End-of-life announcement for CoreOS Container Linux Container Linux by CoreOS. CoreOS (Red Hat). Retrieved 6 Oct 2026.https://coreos.com/os/eol/
  37. Red Hat to Acquire CoreOS, Expanding its Kubernetes and Containers Leadership Container Linux by CoreOS. Red Hat. Retrieved 6 Oct 2026.https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadership
  38. coreos/coreos-overlay README Container Linux by CoreOS. CoreOS, GitHub. Retrieved 6 Oct 2026.https://github.com/coreos/coreos-overlay
  39. Oldest commit in coreos/scripts Container Linux by CoreOS. GitHub. Retrieved 6 Oct 2026.https://github.com/coreos/scripts/commit/d74220d7727b063d84520c53185808a5db12fb6c
  40. Announcing the Fedora CoreOS community! Container Linux by CoreOS. Project Atomic (Dusty Mabe). Retrieved 6 Oct 2026.https://projectatomic.io/blog/2018/06/welcome-to-fedora-coreos/
  41. Flatcar Container Linux documentation Container Linux by CoreOS. Flatcar project. Retrieved 6 Oct 2026.https://www.flatcar.org/docs/latest/
  42. Flatcar Linux is now open to the public Flatcar Container Linux. Kinvolk (Chris Kühl). Retrieved 6 Oct 2026.https://www.flatcar.org/blog/2018/04/flatcar-linux-is-now-open-to-the-public/
  43. Microsoft acquires Kinvolk to accelerate container-optimized innovation Flatcar Container Linux. Microsoft (Brendan Burns). Retrieved 6 Oct 2026.https://azure.microsoft.com/en-us/blog/microsoft-acquires-kinvolk-to-accelerate-containeroptimized-innovation/
  44. CNCF project page, Flatcar Container Linux Flatcar Container Linux. CNCF. Retrieved 6 Oct 2026.https://www.cncf.io/projects/flatcar-container-linux/
  45. Propose Flatcar for Incubation Flatcar Container Linux. CNCF TOC repository. Retrieved 6 Oct 2026.https://github.com/cncf/toc/pull/991
  46. microsoft/azure-container-linux repository metadata Azure Container Linux. GitHub. Retrieved 6 Oct 2026.https://github.com/microsoft/azure-container-linux
  47. Announcing Fedora 21 Fedora Atomic Host. Fedora Magazine. Retrieved 6 Oct 2026.https://fedoramagazine.org/announcing-fedora-21/
  48. Fedora Atomic Host Nearing End Of Life Fedora Atomic Host. Project Atomic (Dusty Mabe). Retrieved 6 Oct 2026.https://projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/
  49. Red Hat Accelerates Application Delivery with New Linux Container Innovations Fedora Atomic Host. Red Hat. Retrieved 6 Oct 2026.https://www.redhat.com/en/about/press-releases/red-hat-accelerates-application-delivery-new-linux-container-innovations
  50. Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux Fedora CoreOS. CoreOS (Benjamin Gilbert). Retrieved 6 Oct 2026.https://coreos.com/blog/fedora-coreos-red-hat-coreos-and-future-container-linux
  51. Bringing CoreOS technology to Red Hat OpenShift to deliver a next-generation automated Kubernetes platform Red Hat Enterprise Linux CoreOS. CoreOS (Reza Shafii). Retrieved 6 Oct 2026.https://coreos.com/blog/coreos-tech-to-combine-with-red-hat-openshift
  52. bootc v0.1 bootc. GitHub. Retrieved 6 Oct 2026.https://github.com/bootc-dev/bootc/releases/tag/v0.1
  53. SUSE CaaS (Container as a Service) Platform Makes Applications Easy to Run, Customers More Agile SUSE MicroOS (OS of SUSE CaaS Platform). SUSE. Retrieved 6 Oct 2026.https://suse.com/news/suse-caas-container-as-a-service-platform-makes-applications-easy-to-run-customers-more-agile
  54. An Exciting New Direction openSUSE Kubic. openSUSE Kubic blog. Retrieved 6 Oct 2026.https://kubic.opensuse.org/blog/2018-08-09-newdirection/
  55. Kubic Project Wound Down openSUSE Kubic. openSUSE Kubic blog. Retrieved 6 Oct 2026.https://kubic.opensuse.org/blog/2022-06-10-kubic-retired/
  56. Introduction to Kubic openSUSE Kubic. openSUSE Kubic blog. Retrieved 6 Oct 2026.https://kubic.opensuse.org/blog/2018-03-22-introduction/
  57. rancher/os release v0.0.2 RancherOS (1.x). GitHub releases. Retrieved 6 Oct 2026.https://github.com/rancher/os/releases/tag/v0.0.2
  58. rancher/os release v1.5.8 RancherOS (1.x). GitHub releases. Retrieved 6 Oct 2026.https://github.com/rancher/os/releases/tag/v1.5.8
  59. rancher/os README RancherOS (1.x). GitHub. Retrieved 6 Oct 2026.https://github.com/rancher/os
  60. SUSE completes acquisition of Rancher Labs RancherOS (1.x). SiliconANGLE. Retrieved 6 Oct 2026.https://siliconangle.com/2020/12/01/suse-completes-acquisition-rancher-labs/
  61. RancherOS v2 README RancherOS v2. rancher/os2. Retrieved 6 Oct 2026.https://github.com/rancher/os2/blob/master/README.md
  62. announce Elemental in header RancherOS v2. rancher/os2. Retrieved 6 Oct 2026.https://github.com/rancher/os2/commit/b954e990
  63. Elemental README Elemental (Rancher OS management stack). rancher/elemental. Retrieved 6 Oct 2026.https://github.com/rancher/elemental/blob/main/README.md
  64. rancher/k3os release v0.1.0 k3OS. GitHub releases. Retrieved 6 Oct 2026.https://github.com/rancher/k3os/releases/tag/v0.1.0
  65. rancher/k3os release v0.21.5-k3s2r1 k3OS. GitHub releases. Retrieved 6 Oct 2026.https://github.com/rancher/k3os/releases/tag/v0.21.5-k3s2r1
  66. rancher/k3os README k3OS. GitHub. Retrieved 6 Oct 2026.https://github.com/rancher/k3os
  67. update readme to include deprecation notice k3OS. rancher/k3os. Retrieved 6 Oct 2026.https://github.com/rancher/k3os/commit/8cdfdf26
  68. k3OS README k3OS. rancher/k3os. Retrieved 6 Oct 2026.https://github.com/rancher/k3os/blob/master/README.md
  69. Commit history cOS-toolkit. rancher/elemental-toolkit (GitHub API). Retrieved 6 Oct 2026.https://github.com/rancher/elemental-toolkit/commits?until=2021-01-09
  70. Change to new branding (#1466) cOS-toolkit. rancher/elemental-toolkit (git). Retrieved 6 Oct 2026.https://github.com/rancher/elemental-toolkit/commit/b13694f7c4db8c42a808976826bd96ce6ec837eb
  71. First commit c3OS. kairos-io/kairos (git). Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/commit/12518a6a95c4090152aad3d595e077b3722b5204
  72. :art: Rebranding (#130) c3OS. kairos-io/kairos. Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/commit/d6565876
  73. Rebranding to Kairos c3OS. kairos-io. Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/issues/88
  74. README at first commit c3OS. kairos-io/kairos. Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/blob/12518a6a95c4090152aad3d595e077b3722b5204/README.md
  75. README Alternatives section c3OS. kairos-io/kairos. Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/commit/c14f8539
  76. Dockerfile at first commit c3OS. kairos-io/kairos. Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/blob/12518a6a95c4090152aad3d595e077b3722b5204/Dockerfile
  77. README Alternatives section c3OS. kairos-io/kairos. Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/commit/c14f85399dfdb2cab19fe2bbc29499f7a46c12cd
  78. README project status Kairos. kairos-io/kairos (git). Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/commit/695a52c8
  79. Kairos 1.0 GA announcement Kairos. kairos-io. Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/discussions/159
  80. replace elemental-cli to our fork (#88) Kairos. kairos-io/kairos (git). Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/commit/a9dd91389b4b69f17fce59dc91f705e5d08ce926
  81. Fully drop elemental from kairos (#1441) Kairos. kairos-io/kairos (git). Retrieved 6 Oct 2026.https://github.com/kairos-io/kairos/commit/22d7a418b598db7535049a0df932e9f77988018e
  82. Hadron-Only Artifacts with Ongoing Distro Support Kairos. kairos.io blog. Retrieved 6 Oct 2026.https://kairos.io/blog/2026/02/25/kairos-v4-hadron-artifacts-and-distro-flexibility/
  83. Hadron releases Hadron Linux. kairos-io/hadron (GitHub API). Retrieved 6 Oct 2026.https://github.com/kairos-io/hadron/releases/tag/v0.0.1-alpha
  84. Introducing Hadron: The Minimal, Upstream-First Linux Base for Kairos Hadron Linux. kairos.io blog (author Ettore Di Giacinto). Retrieved 6 Oct 2026.https://kairos.io/blog/2025/12/17/introducing-hadron-the-minimal-upstream-first-linux-base-for-kairos/
  85. Spectro Cloud Announces Hadron A Lightweight Security First Linux Base for Modern Enterprise Edge Deployments Hadron Linux. Business Wire (Spectro Cloud press release). Retrieved 6 Oct 2026.https://www.businesswire.com/news/home/20260128584925/en/Spectro-Cloud-Announces-Hadron-A-Lightweight-Security-First-Linux-Base-for-Modern-Enterprise-Edge-Deployments
  86. README at v0.1.0-alpha.0 Dianemo. siderolabs/talos (GitHub API). Retrieved 6 Oct 2026.https://github.com/siderolabs/talos/blob/v0.1.0-alpha.0/README.md
  87. refactor: rename project to Talos (#211) Dianemo. siderolabs/talos (git). Retrieved 6 Oct 2026.https://github.com/siderolabs/talos/commit/ca9719cd
  88. Talos Systems is now Sidero Labs Talos Linux. Sidero Labs (Steve Francis). Retrieved 6 Oct 2026.https://www.siderolabs.com/blog/talos-systems-is-now-sidero-labs
  89. The Linux Foundation Launches New LF Edge EVE-OS. The Linux Foundation. Retrieved 6 Oct 2026.https://www.linuxfoundation.org/press/press-release/the-linux-foundation-launches-new-lf-edge-to-establish-a-unified-open-source-framework-for-the-edge
  90. LF Edge Momentum Continues with Project EVE Seed Code EVE-OS. The Linux Foundation. Retrieved 6 Oct 2026.https://www.linuxfoundation.org/press/press-release/lf-edge-momentum-continues-with-project-eve-seed-code-project-demonstrations-at-iot-world-and-new-members
  91. Announcing Bottlerocket, a new open source Linux-based operating system purpose-built to run containers Bottlerocket. AWS What's New. Retrieved 6 Oct 2026.https://aws.amazon.com/about-aws/whats-new/2020/03/announcing-bottlerocket-a-new-open-source-linux-based-operating-system-optimized-to-run-containers/
  92. bottlerocket-kernel-kit grub source Bottlerocket. bottlerocket-os/bottlerocket-kernel-kit (GitHub), cloned 2026-10-06. Retrieved 6 Oct 2026.https://github.com/bottlerocket-os/bottlerocket-kernel-kit/blob/develop/packages/grub/Cargo.toml
  93. signpost README Bottlerocket. bottlerocket-os/bottlerocket-core-kit (GitHub), develop at 2d7f4ea (2026-10-02). Retrieved 6 Oct 2026.https://github.com/bottlerocket-os/bottlerocket-core-kit/blob/2d7f4ea397a706cb7bea705d35437e96db2bebc0/sources/updater/signpost/README.md
  94. A new, transactionally updated "snappy" Ubuntu Core Ubuntu Core. Canonical (Ubuntu blog). Retrieved 6 Oct 2026.https://ubuntu.com/blog/a-new-transactionally-updated-snappy-ubuntu-core
  95. Snapcraft reference: bases Ubuntu Core. Canonical. Retrieved 6 Oct 2026.https://ubuntu.com/docs/snapcraft/stable/reference/bases/