ublue-os/aurora: a Fedora based desktop that ships as an image

A desktop that arrives as a built image

Aurora is described as a delightful KDE desktop experience for end-users that are looking for reliability and developers for the most-hassle free setup, with zero maintenance included. The repository description is shorter and blunter: the ultimate productivity workstation.

The mechanism is bootc. The topic tags list bootc, fedora, kde, linux and oci, and the repository layout confirms the shape of the thing. There is a Containerfile.in, a build_files and a build_scripts directory, a Justfile, a cosign.pub, an artifacthub-repo.yml, an image-versions.yml, a .devcontainer.json and a quay.io-fedora-ostree-desktops.pub file.

So this is not a distribution you install with a package manager and then patch for years. It is an operating system image, built in CI, published as a container artifact, and consumed as a disk image. The release naming makes the rhythm visible: stable-20261020.1, stable-20261013.1 and stable-20261006.1, with the release notes naming the Fedora release in the tag, F44.20261020 for the first one. Those are weekly builds, and the version carries the date and the upstream Fedora point release.

The audience is stated plainly. For end users who want reliability without administration, and for developers who want a working environment on the first boot. The distribution channels are the download link at getaurora.dev and the OCI registry, with a weekly device count badge in the README.

The interesting design choice is that the upstream Fedora base is not exposed to the user. You get a defined image, and the upgrade path is a new image, not a package update.

Secure boot with a key you are told the password for

Secure Boot is supported by default on these systems, and the README is unusually direct about how to enrol it. After the first installation you are prompted to enrol the secure boot key in the BIOS, and when prompted you enter the password universalblue.

A shared, published password in a README is worth pausing on. The key here is the project's own signing key, and the password is the enrolment secret for it. That is a design choice aimed at removing the single most common reason people turn Secure Boot off, which is that enrolling a custom key is a confusing process. The trade is that anyone with the published password can sign their own kernel, which matters for the threat model of a machine that is not yours.

If you skip the step during initial setup, the README gives a terminal command to do it later:

ujust enroll-secure-boot-key

And if you want to enrol the key before installation or before a rebase, you download the key and run mokutil directly:

sudo mokutil --timeout -1
sudo mokutil --import public_key.der

The public key itself lives in the root of the akmods repository, and the README links the file as public_key.der. The timeout of -1 on mokutil is what makes the enrolment prompt wait indefinitely rather than expiring.

The pre-installation route is the one that matters for anyone scripting image deployment, since a machine that is already installed can still be fixed afterwards but an unattended install cannot.

This is also where the design shows its open-source commitments. The key is published, the enrolment tooling is in the image, and the whole flow is documented in the README of the image repository. There is no vendor holding back a signing key for enterprise customers.

Where the repository ends and the images begin

The repository is not the whole product, and the README says so directly. The system_files, flatpak and logos directories have been moved to a separate repository, get-aurora-dev/common. The akmods repository, which holds the public key, is a third one under the ublue-os organisation.

That split is a consequence of how the image is built. A bootc image assembles a root filesystem from a base image, the system files that configure the desktop, and a set of Flatpaks that provide the applications. The common repository holds the parts shared by more than one image, so that a change to the desktop configuration lands in every image at once rather than being copied into each.

The documentation structure mirrors that. The README lists four places to read, in a deliberate order: discussions and announcements, which is strongly recommended, then the documentation at docs.getaurora.dev, then the contributing guide at universal-blue.org, then the local building guide. Announcements first is a reasonable priority for a project that ships weekly images, since a change in the base image can affect users whether or not they asked for it.

For anyone who wants to build an image themselves, the local building guide and the Justfile are the entry points. The Justfile is worth noting: the project's primary language is recorded as Just, which says something about how much of the workflow is expressed as recipes rather than shell scripts.

The build configuration is in the Containerfile.in, and the .devcontainer.json means the build environment itself can be developed in a container, which is a sensible way to avoid needing the full toolchain locally.

The signals the project publishes about itself

The badges in the README tell you what the maintainers think matters, and the choice of badges is itself informative.

There are build status badges for the stable image workflow and for the latest images built from the main branch, so you can see at a glance whether the current development image is passing. There is a Codacy badge for code quality. There is a DeepWiki badge pointing at an aurora-docs project, which is an automatically generated explanation of the codebase.

The most substantive signals are the Linux Foundation ones. The README carries an LFX Active Contributors badge and an LFX Health Score badge for the aurora project, plus an OpenSSF Scorecard badge. The LFX badges are the standard for open source project governance health in the Linux Foundation ecosystem, and the Scorecard checks the things that actually matter for a project that asks you to install a signed operating system image, such as whether the build is reproducible and whether the releases are signed.

The cosign.pub file in the repository root is the direct evidence for the last point. Cosign is the signature tooling for container artifacts, and publishing the public key in the repository is what allows a user to verify that the image they downloaded was built by the project and not by someone else.

The image-versions.yml file and the quay.io fedora ostree desktops public key are the other two pieces of that story, one for the version catalogue and one for the OSTree based desktop images published to a Quay registry. The registry hosting, the signature key and the weekly cadence together are the operational shape of the project, and they are what distinguishes a bootc image project from a set of installation scripts.

What zero maintenance actually means, and what it costs

The zero maintenance claim needs unpacking, because it is a claim about who does the work rather than about how much work there is.

For the end user, the model is: download an image, write it to a drive, boot it, and get a working KDE desktop that arrives with the security updates already applied. There is no package manager to learn, no upgrade path to think about, and no decision to make about which repository to trust. The cost is that you do not control the base image. When the image moves to a new Fedora release, as the stable-20261020.1 tag with F44 in its name shows, the kernel and the userland move with it, and the applications you rely on may or may not be present in the new build.

That is the real limitation, and it is a design decision rather than a bug. A bootc image is reproducible and small, and a reproducible image is a good deal for a laptop where you want the same state every time you reinstall. It is a poor fit for a machine whose kernel must stay on an older point release, or for a developer whose toolchain needs a specific system library version that the new base does not carry.

The second limitation is the Flatpak-centric application model that the moved flatpak directory implies. Applications delivered as Flatpaks are sandboxed and update independently of the system, which is a good property, and it also means the set of available applications is bounded by what has been packaged. A proprietary or niche application that nobody has packaged simply is not there, and the system_files fallback is thin.

The third is that the shared secure boot password is a real trade, as described earlier. For a personal laptop, the convenience of a frictionless enrolment is worth more than the theoretical exposure. For a machine holding credentials that matter to somebody else, it is a decision you should make deliberately rather than inherit.

Compared with the alternatives, the picture is clearer. A traditional distribution gives you full ownership and a decade of control, and it also gives you the upgrade work, the driver work and the security patch work. A container-based developer image gives you a similar disposable workflow with less disk and no installation step at all. Aurora is closer to the first model than the second, with the packaging convenience of the second.

Adopting it without getting in the way of it

A few practical notes for someone deciding whether to put Aurora on a machine.

The distribution is the download link in the README, and the docs site is the place for the actual install walkthrough. The README does not contain a command to write the image, so treat getaurora.dev as the starting point rather than looking for a one-liner here.

Enrol Secure Boot during the first setup if you possibly can. The ujust command exists for later, but doing it during setup avoids a machine that boots with Secure Boot effectively disabled, and the mokutil route exists if you are deploying an image unattended.

Read the announcements before you update, since a new stable image can change the base release. The tag itself tells you what to expect, because the Fedora release is encoded in the version string.

The one thing to verify first is hardware support, and the README does not enumerate a compatibility list, so the announcements and the discussions are where you will find whether your machine's wireless card, graphics stack or fingerprint reader works. For a KDE desktop with a standard laptop configuration this is usually uneventful, and for a machine with unusual hardware it is where the risk sits.

If you are a developer who wants to contribute rather than install, the contributing guide and the local building guide are the two documents to read, and the Justfile is where the recipes live. The project publishes a weekly device count badge, which suggests it tracks how many machines are running its images, and that number is a reasonable proxy for whether the effort behind the weekly cadence is sustained.

Editorial conclusion

Adopt Aurora if you want a working KDE Linux desktop without installing and updating a distribution, especially on hardware where you want secure boot with a pre-enrolled key. Do not adopt it if you need to own your operating system image, if you depend on packages that are not in the Fedora base, or if you need a kernel or driver older than the image ships. Verify first that your hardware is on the supported list for your chosen image, that the secure boot key enrolment step actually completed, and that the build you install matches the Fedora release your applications expect.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ublue-os/aurora on GitHub