# Bluefin: a cloud-native Linux workstation built from OCI images

> Bluefin is an atomic Fedora-based desktop from the Universal Blue project, shipped as container images and updated like a cloud workload. Here is what the repository actually documents, how to install it, and where it does not fit.

**ublue-os/bluefin** — The next generation Linux workstation, designed for reliability, performance, and sustainability.

- Repository: https://github.com/ublue-os/bluefin
- Website: https://projectbluefin.io
- Stars: 2,604 · Forks: 260
- Language: Shell
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/ublue-os-bluefin

## The problem Bluefin targets: a workstation that does not drift

A conventional Linux desktop accumulates state. Packages are installed from a repository, a PPA or a third-party script, and over a year or two the machine becomes something nobody can reproduce. Bluefin's answer is to treat the operating system as a build artifact. The repository describes it as a cloud-native desktop operating system, and the topics attached to it are bootc, gnome and oci. That combination tells you the intended audience: engineers who already think in terms of images, tags and rollbacks, and who want their laptop to behave like a deployment target rather than a pet.

The project frames two audiences in the README. For end users it promises a system as reliable as a Chromebook with near-zero maintenance. For developers it points at integrated container tools, declarative system management and CI/CD integration. Those are different promises, and the second one is the more defensible. A user who never opens a terminal gets atomic updates; a developer gets a machine whose base layer is defined by a Containerfile in the repository and rebuilt on a schedule. The releases listed for the project follow a weekly cadence, with stable tags such as stable-20260922 carrying a Fedora version and a commit hash.

## How the image pipeline works: Containerfile in, bootc out

The repository layout is the clearest explanation of the architecture. There is a Containerfile at the top level, a build_files directory, a system_files directory, a Justfile, and an image-versions.yml. The build reads the pinned versions from image-versions.yml, layers the files under system_files on top of a base image, and produces an OCI image. Because the deliverable is an image and not a package set, the same artifact can be pulled by a container runtime or booted as a system by bootc.

That is the whole mechanism, and it has consequences worth naming. Nothing in this design lets you install a system package with dnf and expect it to survive the next update, because the next update replaces the image. The Justfile is where the project puts its task runner entries, which is how a user triggers project-specific operations without memorising the underlying commands. The build_files directory holds the scripts that assemble the image during CI. If you want to know what is actually in your system, the Containerfile and system_files are the authoritative answer, not the running machine. The README does not document a rollback procedure, so a reader should treat the update and rollback story as something to confirm in the project's documentation rather than assume from the OCI framing.

## Installing Bluefin and enrolling the Secure Boot key

The README does not walk through the installer. It points to the project site for installation options, so the first step is to visit projectbluefin.io and use the scene picker there to choose an image. What the README does document in detail is Secure Boot, which is supported by default and uses the project's own key rather than the distribution key. During the first installation you are prompted to enroll that key in the BIOS, and the password to enter at the prompt is universalblue.

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

```bash
ujust enroll-secure-boot-key
```

The ujust command is the project's task runner entry point, and enroll-secure-boot-key is the specific recipe name printed in the README. If you would rather enroll the key before installing or rebasing, the public key is published in the root of the akmods repository, and the README gives these two commands:

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

The first disables the timeout on the MOK enrollment prompt, and the second queues the key for import. You will be asked to set a password that you then enter in the MOK manager on the next boot. Expect the machine to reboot into a blue MOK management screen rather than your desktop; if the key is not enrolled, modules signed with the project key will not load under Secure Boot.

## Where Bluefin is the wrong tool

The immutable base is the feature and the limitation at the same time. If your workflow depends on building a kernel module against the running kernel, or on a package that is not in the image and not available as a Flatpak, you are working against the design rather than with it. The project does ship an akmods repository with signed kernel modules, which is how out-of-tree drivers are handled, but that set is curated. A driver the project has not built is not something you can simply compile on the host and keep across updates.

There is a second, quieter cost. Debugging is different. On a traditional system you can inspect what changed between two package transactions. Here the unit of change is an image tag, and the release notes carry a Fedora build and a commit hash rather than a list of packages. That is more reproducible and less granular. Anyone who relies on reading package changelogs to diagnose a regression will find the trail shorter than they are used to. Finally, the README's claim of near-zero maintenance applies to the base system. It says nothing about the applications you install on top, and those still need updating on their own schedule.

## Bluefin against a conventional Fedora Workstation

The honest comparison is not against another immutable desktop but against a plain Fedora install with GNOME. Fedora Workstation gives you dnf, a mutable root, and a package for almost everything. Bluefin gives you an image, a task runner, and a smaller set of supported ways to change the system. The difference in approach is not cosmetic. On Fedora, a broken update is repaired by downgrading packages or by reading a forum thread. On Bluefin, the equivalent move is to boot a previous image or rebase to a different tag, which is a coarser operation but a more predictable one.

A second comparison worth making is against building your own image. The Universal Blue approach exists precisely so that you do not have to maintain a Containerfile and a CI pipeline yourself. The repository you are reading is one such image. If your needs are close to Bluefin's defaults, consuming the project's image costs you nothing. If they are far from the defaults, the project's own pattern is to build your own image on top rather than to modify the running system, and that is a real engineering commitment, not a configuration change.

## Maintenance cadence, licensing and what to verify

The repository is not archived, and the last push was on 2026-09-24, four days before this writing. Stable releases arrive weekly, with stable-20260908, stable-20260915 and stable-20260922 in the recent list, each tagged with a Fedora build and a commit. That cadence is the maintenance story: you do not patch, you take the next image. The upgrade cost is therefore mostly in the applications layer and in anything you have customised outside the image. Because the base is replaced wholesale, customisations that live in the image definition survive, and customisations that live in the running filesystem do not.

The project is licensed Apache-2.0. That is a permissive licence, and it means you can redistribute and modify the image definition, including for internal use. It does not settle the licensing of everything inside the image. The Fedora base, the GNOME desktop and any bundled components carry their own licences, and the README does not enumerate them. If you are shipping a derived image to other people, that inventory is your responsibility to assemble. Nothing here is legal advice, and a derived image that includes proprietary firmware or drivers needs its own review.

## Conclusion

Adopt Bluefin if you want a Fedora GNOME workstation whose system image is built and updated like a container, and you are comfortable with an immutable root and a rebase-based upgrade path. Do not adopt it if you need to install kernel modules or system packages the traditional way, or if your hardware depends on out-of-tree drivers the project's akmods set does not cover. Before installing, verify three things: that your machine boots the published image, that you have the Secure Boot key enrollment password and mokutil available, and that the applications you depend on are available as Flatpak or inside a container, because the base image is not meant to be modified in place.

## FAQ

### How do I install Bluefin?

The README does not list installer steps. It directs readers to projectbluefin.io, where the scene picker is used to explore installation options.

### What is Bluefin?

Bluefin is described in its README as a cloud-native desktop operating system built on Fedora and GNOME, delivered as OCI images with atomic updates. The repository topics are bootc, gnome and oci.

### How do I use Bluefin after installing it?

The README points to the project documentation for a feature walkthrough and shows ujust as the task runner, for example ujust enroll-secure-boot-key. Application installation on top of the base image is not covered in the README.

## Sources

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

---

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