Skip to main content
Version: v4.0.1

Bring Your Own Image (BYOI)

Kairos still supports multiple Linux distributions. What changed is where official prebuilt artifacts are focused: docs and default release flow now center on Hadron.

If you run Ubuntu, Alpine, openSUSE, Debian, Fedora, Rocky, or another supported base, the recommended path is BYOI: build and publish your own images while keeping Kairos lifecycle and upgrade semantics.

Why BYOI​

  • You keep full control over release cadence and patch windows.
  • You can align base OS updates with your own security and compliance process.
  • The tested distro matrix remains broad in kairos-init, even when not all artifacts are published by default.

Pick your pipeline path​

1) GitHub-only path (fastest)​

Use the Kairos Factory GitHub Action to build and publish artifacts in GitHub Actions.

  • Good default for small teams.
  • Works well with free GitHub-hosted runners for many workflows.
  • Keeps your build logic in repo and easy to audit.

Start here: Kairos Factory reference

2) Generic CI path (any CI system)​

Use AuroraBoot and Kairos Factory tooling directly in your own CI pipeline (GitHub, GitLab, Jenkins, Tekton, etc.).

  • Same model, no GitHub lock-in.
  • Full control over runners, registries, and signing.

Start here:

3) Kubernetes-native path (Kairos Operator)​

Use the Kairos Operator to build OS artifacts directly in Kubernetes using the OSArtifact CRD.

  • Build ISOs, cloud images, and netboot artifacts as Kubernetes-native resources.
  • Integrates with existing Kubernetes workflows and GitOps patterns.
  • Manage upgrades and operations on Kairos nodes from within Kubernetes.

Start here: Kairos Operator

Suggested workflow​

  1. Select your base distribution and release.
  2. Build core/standard image with Kairos Factory tooling.
  3. Publish to your own registry/release assets.
  4. Use that image reference for installs, resets, and upgrades.
  5. Rebuild on your cadence when upstream distro or Kairos updates are needed.

Notes on legacy examples​

Some docs still include concrete flavor/release image examples to show naming patterns. Treat them as templates. For non-Hadron flavors, prefer publishing your own image artifacts and referencing those in production workflows.