If you've built Kairos from source in the last few days, you've noticed: kairos-agent, immucore, kairos-sdk, kairos-init, and kcrypt-discovery-challenger are gone. Not deleted. Moved. They now live inside kairos-io/kairos, as agent/, immucore/, sdk/, kairos-init/, and kcrypt/.

TL;DR, if you just need to keep building:

• The five repos are archived, not deleted. Their code, full git history, and existing published tags all still work. Receipts at the bottom if you want them.
• Using the SDK: import github.com/kairos-io/kairos/sdk/... (e.g. sdk/bus, sdk/collector, sdk/machine) instead of github.com/kairos-io/kairos-sdk. Code pinned to old kairos-sdk tags keeps building unchanged.
• Using kairos-init, kairos-agent, immucore, kcrypt-discovery-challenger: same binaries, same container images, same tag pattern, just built from the monorepo now, versioned off kairos-io/kairos's own tag instead of their own.
• Their next release will jump from their own v0.x / v2.x number straight to the shared v4.x.x line. That is not a wall of breaking changes compressed into one release. See "About that version jump" at the bottom before you panic.
• The SDK doesn't get this jump at all: it's not an independently tagged artifact anymore, so there's no "next sdk version" to be surprised by. Details below.

Dear community,

For the past few months I've been working on RISC-V support for Kairos. I think this is a very exciting technology and one where I'd enjoy seeing the easy lifecycle management that Kairos brings paired with. In this post you'll see an emulated k3s cluster on an Ubuntu 24.04 Kairos image. I think it's time to get out of the VM, and here's where you come in. If you have a RISC-V board, I'd like to invite you to do some testing to help us run on metal.

Kairos v4.2.0 is now available.

This release opens up new places to run Kairos and new ways to extend it: boot entirely from RAM while still keeping persistent config and data on disk, deploy through Canonical MaaS, and extend Hadron images with the first extension layers. It also brings initial NVIDIA DGX Spark support, a hardening baseline for Hadron, and steady progress on confidential computing.

Kairos ships two kinds of images. A "core" image is just the immutable OS. A "standard" image is that same core with a Kubernetes layer baked in: the k8s provider plugin, edgevpn, and the k3s or k0s binaries with their service units. Those extra files are added at build time by kairos-init, and once they are in the image they are part of it for the life of that release.

That packaging is convenient, but it ties two things together that do not really need to be tied: the operating system and the Kubernetes distribution running on top of it. I spent some time on a proof-of-concept that pulls them apart, and I would like to show you what it looks like and, more importantly, hear whether you think it is worth pursuing.

The repository is here: https://github.com/jimmykarily/provider-kairos-extension

Kairos v4.1.0 is now available.

This release improves the path from building a Kairos image to deploying and managing real nodes. kairos-agent now includes phone-home support, which works together with AuroraBoot v0.20.0 and its web UI when you run it in fleet server mode. Nodes produced through that flow can come online, report back after first boot using phone-home, and show up in AuroraBoot’s node manager.

Behind that story, v4.1.0 also ships Hadron v0.2.0 for Hadron-based Kairos images, Ubuntu 26.04 support in kairos-init, boot and install/disk hardening, broader distro compatibility, and release automation improvements. These layers all support the same operational direction: a dependable lifecycle around immutable images.

Kairos community,

We are preparing the next major step in our CNCF journey: applying to move from Sandbox to Incubation.

To do that, we need to demonstrate healthy and diverse real-world adoption. As part of the official CNCF TOC project lifecycle and process, projects are expected to provide 5-7 adopters willing to be interviewed during due diligence.

Today, we are inviting organizations using Kairos to participate as adopters and help us through this milestone.

We also understand adoption takes time. If you are currently in a proof-of-concept stage, that is absolutely okay. We would still love to talk, learn from your experience, and help you move toward pre-production and production in any way we can.

Kairos v4.0.0 is the result of a clear architecture path we have been building over time: first standardizing image creation with kairos-init, then making that flow easy to run anywhere with Kairos Factory and kairos-factory-action, and finally introducing Hadron.

In March 2025, we introduced kairos-init, a foundational shift that removed Dockerfile-heavy distro logic and standardized how we transform OCI bases into Kairos images.

From there, we focused on operationalizing that model so anyone could run it. With Kairos Factory, users can build and maintain their own Kairos pipelines using the same tooling we run in production.

In December 2025, we introduced Hadron, our upstream-first Linux base for immutable systems. In v4, Hadron artifacts are what the project publishes in its release flow.

At the same time, distro flexibility remains core to Kairos. This is visible in active community work such as Oracle Linux support in kairos-io/kairos#3987.

For additional migration and build context, read Hadron-Only Artifacts with Ongoing Distro Support.

Starting with Kairos v4, the Kairos project will publish Hadron-based artifacts only.

This decision allows us to reduce maintenance costs, focus engineering effort where it has the most impact, and ship improvements faster.

We are happy to welcome William Rizzo as a new Kairos maintainer.

William is a CNCF Ambassador and Linkerd Ambassador, and he currently works at Mirantis as a Global Field CTO. He helps organizations design, build, and run platforms across edge, AI, and platform engineering. His background spans engineering, product ownership, pre- and post-sales, and consulting, with experience in HPC, storage, and large-scale distributed systems.

Open source and cloud-native communities are a major part of William's professional identity. He actively volunteers in several Cloud Native groups and helps organize KCD Netherlands. He also brings public speaking experience from community talks. He is a strong addition to the team, bringing years of experience in the field and a collaborative, community-first approach.

The cloud-native and edge-computing world demands systems that are small, reliable, and predictable. For years, the Kairos project has empowered users to turn mainstream Linux distributions, such as Ubuntu, Alpine, Debian, Fedora and more, into immutable, image-based operating systems with secure, atomic A/B updates.

That mission remains core to us. But in transforming traditional distributions, we continually encountered friction: the inherited bloat of legacy package managers, sprawling dependency graphs, and downstream patches that increase image size and boot time.