# uCore is Fedora CoreOS turned into a general purpose server image

> uCore is a set of Fedora CoreOS based server images for container hosting, storage and virtualization, published to ghcr.io with three release channels and signed with a checked in public key. It suits an operator who wants an immutable, auto updating base image, and it is a build recipe rather than a tool you configure.

**ublue-os/ucore** — An OCI base image of Fedora CoreOS with batteries included

- Repository: https://github.com/ublue-os/ucore
- Website: https://projectucore.org
- Stars: 699 · Forks: 61
- Language: Shell
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/ublue-os-ucore

## A base image, not an installer

uCore is a set of Fedora CoreOS based server images for container hosting, storage and virtualization, and the repository describes itself as an OCI base image of Fedora CoreOS with batteries included. That is a narrower thing than a Linux distribution, and the distinction matters when you read the rest of the documentation. There is no installer to download and no package manager to configure. What exists is a set of images, published to ghcr.io, that you pull and run. The project site at projectucore.org is where the substantive documentation lives, covering image selection, installation instructions, operating guides and announcements, and the README is a signpost to it rather than a manual. The get started list in the README is a short set of links, one to choose an image and tag, one to install uCore, one to switch an existing system to uCore, one to browse the documentation and one to read the project announcements. That last one is worth noting, because a project that publishes announcements separately from documentation is telling you that the images change underneath you.

## Three channels, moving at different speeds

The build badges at the top of the README name three workflows, and they correspond to the three release channels. There is an lts workflow, a stable workflow and a testing workflow, and the recent releases in the history are all from the testing channel, with tags named testing-20261016, testing-20261015 and testing-20261014, each carrying the Fedora CoreOS build it was produced from in the title. The three channels therefore differ in update frequency, and the names tell you which one to use for which purpose. The stable channel is what you would run in production, the long term support channel is the one that changes least often, and testing is where changes land first. The daily movement of the testing tags is not a problem in itself, it is the point, because it is how a rebuild lands in the registry and becomes available. What it does mean is that pinning matters. If your deployment references a mutable tag, you are consuming whatever the channel currently holds, so the image digest is the thing to record.

## Verification is the part that is documented first

The repository carries a cosign.pub file at the top level, and the README points to a verification and build transparency page for image signatures, package provenance and SBOMs. Put together with the OpenSSF Scorecard badge in the header, that tells you the project treats supply chain evidence as part of the product rather than an afterthought, which is a reasonable expectation for an image whose whole selling point is that it replaces the host OS. The practical question for a consumer is what you do with the key. The public key is in the repository, which means your trust anchor is the repository itself, and that is worth being explicit about. For a base image that you will deploy across a fleet, you would normally verify the signature at pull time against a key you have already trusted, rather than fetching the key at the moment you pull, because the latter protects against nothing. The presence of signatures, provenance and SBOMs lets you do that check. Whether you wire it into your admission controller or into your CI is a decision the project leaves to you.

## Rebasing, and the one example shipped in the tree

The get started list includes a page on switching an existing system to uCore, and the repository ships a single example under examples/, a file named ucore-autorebase.butane. The name is the whole point of the feature. A Butane file is a declarative description of a machine, and an autorebase one describes a configuration that is applied on top of a new base image release, so that a host running uCore can pick up a new image and re-apply its local configuration without a manual rebuild. That is the operationally interesting part of an immutable image approach. If every host has local customisation, then every base image update becomes a migration project, and an autorebase description turns that migration into a declarative step. The example file being the only one shipped suggests the mechanism is a starting point rather than a library of patterns, and the documentation site is where you would find how it composes with your own configuration. The README also points at a ROADMAP.md and a SECURITY.md in the repository root, which is where the project's own priorities and disclosure process are described.

## The build recipe is a Containerfile template with a Justfile

How the images are produced is visible in the repository layout. The top level holds the README, the ROADMAP, the SECURITY policy, the cosign public key, a renovate.json for dependency updates, the examples directory and the ucore/ directory, which is where the build actually lives. Inside that directory are the build workflows under .github/workflows/, the image build recipes in ucore/Containerfile.in and the package installation scripts, the build commands and checks in a Justfile, and a set of example Containerfiles. The .in suffix on the Containerfile template tells you the recipe is generated rather than static, which is what you would expect from an image that has to bake in a moving set of package versions for several CoreOS streams. The Justfile is the entry point for the checks, and the contributing section says to run the repository checks from ucore/ with just check, reporting bugs and feature requests in GitHub Issues. So the contribution loop is small and mechanical, which is what you want from a repository that mostly orchestrates other people's packages.

## What the project is for, and what it is not

The clearest statement of intent is the one line in the README, that uCore is a set of Fedora CoreOS based server images for container hosting, storage and virtualization. Three workloads, and a base for each rather than a finished product for any of them. That tells you what to expect and what not to. You are not getting a desktop environment, a package repository with thousands of applications, or a distribution you tune with configuration management. You are getting a minimal, immutable, auto updating Linux that a container runtime or a hypervisor runs, and everything you add on top is your own responsibility. The advantages of that model are well understood by this point in the industry, so the interesting question is not why but whether it fits your estate. If your workloads are containers on a fleet, the value of a small image that updates itself and carries signed provenance is high. If you want a mutable server you can apt install your way through, it is the wrong shape and the CoreOS family has never been the right answer.

## Conclusion

Adopt uCore when you want a small, immutable and self updating Linux base image for containers, storage or virtual machines, and you are willing to follow the upstream CoreOS release rhythm. Do not adopt it as a general purpose distribution for a workstation or a bespoke appliance, since the point of the project is a narrow server image built from CoreOS. Verify first which channel you want, since testing builds move daily while lts and stable move more slowly, that your container runtime can pull from ghcr.io, and that you have a way to verify the image signatures and SBOMs the project publishes.

## FAQ

### What is uCore and what is it based on?

uCore is a set of Fedora CoreOS based server images for container hosting, storage and virtualization, described as an OCI base image of Fedora CoreOS with batteries included. The images are published to ghcr.io and the project site projectucore.org carries the image selection, installation and operating guides.

### What release channels does uCore have?

Three, corresponding to the lts, stable and testing build workflows. The recent releases in the history are all testing tags named by date, each carrying the Fedora CoreOS build it came from, and they move daily, so pinning to an image digest rather than a mutable tag is the safer approach for production.

### Can I verify the uCore images?

Yes. The repository contains a cosign.pub file at the top level, and the verification and build transparency documentation covers image signatures, package provenance and SBOMs. The repository also carries an OpenSSF Scorecard badge. Since the public key lives in the repository, you would normally pin it in your own trust store rather than fetching it at pull time.

### How do I run the uCore repository checks?

From the ucore/ directory, with just check, according to the contributing section. The build recipes live in ucore/Containerfile.in with the package installation scripts alongside them, and the build commands and checks in a Justfile, with the workflows under .github/workflows/.

## Sources

- [License: Apache-2.0](https://github.com/ublue-os/ucore/blob/main/LICENSE)
- [Project website](https://projectucore.org)
- [README](https://github.com/ublue-os/ucore/blob/main/README.md)
- [Releases](https://github.com/ublue-os/ucore/releases)
- [ublue-os/ucore on GitHub](https://github.com/ublue-os/ucore)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ublue-os-ucore