cloudparts

KernelCI

Continuous integration for the upstream Linux kernel: it builds kernel trees in many configurations, boots and tests them on real boards in community labs, and collects results from other kernel CI systems in one public database.

Linux Foundation project
What it is
CI/CD pipelines
Used for
Automated testing
Type
Open source
Made by
KernelCI Foundation (Linux Foundation)
Foundation
The Linux Foundation, joined October 2019. Run as the KernelCI Foundation, a member-funded Linux Foundation project
License
LGPL 2.1
Facts checked
28 October 2026
Website Source code

What it is

The Linux kernel runs on more hardware than any other operating system, and no single company owns all of it. KernelCI is the shared answer. Its pipeline, Maestro, watches dozens of kernel trees; when a branch moves, it builds the kernel in many configurations and architectures and sends boot and test jobs to hardware labs. KernelCI runs no labs itself: member companies and individuals connect theirs, either as LAVA labs that receive jobs pushed from Maestro or as pull-mode labs that poll Maestro’s API from behind a firewall. A single mainline checkout can produce sixty-odd builds, nearly two hundred boots and tens of thousands of test results across well over a hundred hardware platforms.

Results go into KCIDB, a common database with a fixed JSON schema that other kernel CI systems also submit to, such as Red Hat’s CKI, Linaro’s LKFT and syzbot, so one dashboard shows one tree’s results from all of them. The web dashboard at dashboard.kernelci.org, backed by PostgreSQL, lets maintainers browse builds, boots, tests and known issues and subscribe to email reports. kci-dev is the command-line client: it lists results, compares two commits to find regressions, can act as a gate in another CI pipeline and, since 2026, serves the same data to AI assistants as an MCP server.

The project is run by the KernelCI Foundation under the Linux Foundation. Its premier members are Arm, the Civil Infrastructure Platform, Collabora, Google, Linaro, Microsoft, Qualcomm, Red Hat and Texas Instruments, and a seven-person technical steering committee, chaired by Ben Copeland of Linaro and including Greg Kroah-Hartman, sets direction. In 2026 regzbot, the kernel’s regression tracker, joined the project, and Linaro donated its TuxMake and TuxRun build and test tools.

Why teams pick it

  • Tests on real hardware that no one company has: boards from many vendors and labs, on architectures from Arm and x86 to RISC-V
  • One public place for kernel test results, merging KernelCI’s own runs with other CI systems through KCIDB’s shared schema
  • Labs of any technology can join: LAVA labs receive jobs, and pull-mode labs need only outbound connections to Maestro and KCIDB
  • Free results for anyone: reading the dashboard or running kci-dev results needs no account or token

Watch out for

  • Built for the upstream Linux kernel and its trees, not as a general CI service for other software
  • Coverage depends on donated labs: a board is tested only if someone has connected it
  • It tests branches after they land in a tree; testing patches straight from the mailing list through Patchwork is not available yet
  • Submitting results or jobs needs a token, requested through a GitHub issue, and private or pre-release work needs a self-hosted instance

Alternatives

What all ci/cd pipelines have in common →Compare side by side →
Argo CDOpen sourceGitOps delivery for Kubernetes: a controller in the cluster keeps what’s running identical to the manifests in a Git repository.CodecovCommercialA hosted code coverage service: CI jobs upload the coverage reports their tests produce, and Codecov merges them per commit and reports on each pull request how well the changed lines are tested, with a status check that can block the merge.GitHub ActionsCommercialCI/CD built into GitHub: YAML workflows in the repository run on GitHub’s VMs or your own machines whenever something happens in the repo.JenkinsOpen sourceThe self-hosted automation server much of CI started on: a Java controller that hands jobs to agents, more than 2,300 plugins, and pipelines written as a Jenkinsfile.SigstoreOpen sourceSigning for releases, images and packages without keys to manage: a short-lived certificate tied to a login or CI job, and a public log of every signature.TektonOpen sourceBuilding blocks for CI/CD systems as Kubernetes resources: each Task runs as a pod, each step in it as a container, and Pipelines chain Tasks together.

How it fits with other technologies

kci-dev: read KernelCI results from a terminal, no token needed · bash

pip install kci-dev

# builds, boots and tests for the latest mainline checkout
kci-dev results summary --branch master --latest \
  --giturl 'https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git'

# only the failed builds on linux-next
kci-dev results builds --branch master --latest --status=fail \
  --giturl 'https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git'

# what regressed or got fixed between the last two mainline checkouts
kci-dev results compare --branch master \
  --giturl 'https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git'

# one board across every tree
kci-dev results hardware summary --name mediatek,mt8195 --origin maestro

See it in a real stack

No architecture uses KernelCI yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2014–2026

In 2014 kernel testing was mostly done in private, each company on its own hardware. Arm SoC maintainers Kevin Hilman and Olof Johansson had small board farms at home and began automating boot tests of every tree and emailing the results; with Linaro engineers Tyler Baker and Milo Casagrande, and Alan Bennett, that side project became kernelci.org. By 2016 board farms at Collabora, BayLibre, Linaro, Pengutronix, Free Electrons, TI and others contributed boots, most of them scheduled with Linaro’s LAVA, and by 2017, run by Linaro and BayLibre, it built over 260 configurations per commit and booted them on over 100 boards.

On 28 October 2019, at Open Source Summit Europe in Lyon, KernelCI became a Linux Foundation project with BayLibre, the Civil Infrastructure Platform, Collabora, Foundries.io, Google, Microsoft and Red Hat as founding members. Its goals were better testing of long-term-support kernels, combining the separate kernel testing efforts, and more compute and hardware; KCIDB, a common results database shared with Red Hat’s CKI and Linaro’s LKFT, followed.

The project then rebuilt its own system. The new Maestro pipeline and web dashboard replaced the original service, which was shut down in early 2025, and a Rust KCIDB-ng API replaced the old submission service later that year. Linaro and ELISA joined in 2025, Arm and Qualcomm became premier members in November 2025, and in 2026 regzbot and Linaro’s Tux tools moved under KernelCI.

Why it’s built this way

Labs owned by others, not by the project
No single organisation can own every board Linux runs on, so KernelCI schedules work onto labs run by members and individuals and lets each keep its own hardware.
One results schema for every kernel CI
Kernel testing was split across separate systems with separate reports. A shared KCIDB schema lets each keep its own pipeline but publish to one database and dashboard.
Pull-mode labs
Corporate labs often cannot expose an API to the internet, so labs can instead poll Maestro and send results to KCIDB, using any lab technology.
Open results, open tooling
Following an “open testing” approach, the dashboard and kci-dev need no login to read, so any kernel developer can check a tree before sending a pull request.

Timeline

  1. 2014

    kernelci.org starts as a side project for automated build and boot tests

  2. 2017

    Over 260 builds per commit, booted on over 100 boards

  3. 2019

    Becomes a Linux Foundation project on 28 October

  4. 2025

    Legacy system shut down; KCIDB-ng replaces the old submission API

  5. 2025

    Arm and Qualcomm join as premier members in November

  6. 2026

    Regzbot joins in May; kci-dev adds an MCP server in September

Sources10 · facts checked 28 October 2026

Improve this page on GitHub