Bluefin OS#

Bluefin is an immutable, container-based Linux desktop operating system built on Fedora Silverblue and part of the Universal Blue project ecosystem. Described as "an interpretation of the Ubuntu spirit built on Fedora technology," Bluefin provides a system as reliable as a Chromebook with near-zero maintenance for end users while offering powerful cloud-native developer workflows through its DX variant. The system is delivered as OCI container images using bootc (bootable containers) for atomic updates and rollbacks.

Bluefin's design philosophy centers on eliminating problems rather than documenting workarounds—"Why spend decades documenting workarounds when you can just remove the problem entirely!"—and rigorously moving away from legacy technologies. The operating system implements a three-layer package management strategy: an immutable system layer, Flatpak for GUI applications with automatic daily updates, and Homebrew for CLI tools. System updates are delivered as complete new images, checked automatically every 6 hours, and applied on reboot, while application updates occur independently without requiring reboots.

The project targets both experienced Linux users and newcomers, particularly developers seeking cloud-native workflows and users who do not want to care about their computer. Founded by three former Ubuntu/Canonical developers, including one who helped launch askubuntu.com, Bluefin is designed to be installed for the life of the hardware without reinstallation and features GNOME desktop integration with a focus on staying out of the user's way.

Architecture and Foundation#

Bluefin is built on Fedora Silverblue with an image-based architecture where the system is delivered as OCI container images. The build process uses a multi-stage container build from ghcr.io/ublue-os/silverblue-main, which integrates ghcr.io/projectbluefin/common for shared configurations and ujust management, and includes ghcr.io/ublue-os/brew for Homebrew integration.

The architecture is modular, built from several OCI container components: @projectbluefin/common (core experience including ujust, MOTD, service units, and GNOME configuration), @projectbluefin/branding (branding assets), @ublue-os/artwork (art assets shared with Aurora and Bazzite), and @ublue-os/brew and @ublue-os/homebrew-tap for Homebrew integration.

Immutability#

Local package layering is locked by default via LockLayering=true in /etc/rpm-ostreed.conf, which prevents mutation of the base OSTree commit (package overlays, overrides, initramfs changes). Running rpm-ostree reset and rebooting always restores the system to pure image mode. The system image remains pristine, making upgrades less problematic with no package-based degradation over time.

Package Management#

Bluefin implements a three-layer package management approach separating system components, GUI applications, and CLI tools.

Flatpak for GUI Applications#

Bluefin defaults to system-wide Flatpak installations with automatic updates enabled by default, running daily at 4:00 AM via systemd timers. Applications are installed from Flathub (not system packages) and updates occur independently without requiring reboots.

Homebrew for CLI Tools#

Homebrew is managed via the projectbluefin/common image and includes containerd, enabling Docker installation directly from Homebrew. Bluefin maintains a custom tap at ublue-os/homebrew-tap for Bluefin-specific packages.

Base System Packages#

The base image includes ~93 packages from Fedora repositories, including bootc, containerd, GNOME tools, backup utilities (borgbackup, restic, rclone), and fonts (JetBrains Mono, OpenDyslexic). Packages are split into FEDORA_PACKAGES and COPR_PACKAGES to prevent COPR supply chain attacks.

Curated Brewfile Bundles#

Bluefin provides a growing set of curated Brewfile bundles installed via the ujust bbrew command:

Update Mechanism#

Bluefin uses bootc (bootable containers) as the primary upgrade mechanism, with the Bluefin repository undergoing drastic refactoring in 2025 to fully embrace bootc after predating the technology. Updates are delivered as complete new images, not individual packages, with the system checking for updates every 6 hours automatically. Updates are applied on reboot, keeping the running system stable, and images are published weekly but can be pushed at any time. The ujust update command uses bootc upgrade by default, falling back to rpm-ostree if package layering is detected.

Update Streams#

Bluefin provides multiple update streams allowing users to select their preferred cadence:

Users can switch between streams and pin to specific dates or versions using tags.

Update Orchestration#

The uupd service coordinates system and Flatpak updates, replacing or supplementing rpm-ostreed-automatic and Flatpak timers. If uupd.timer exists, it is enabled by default; otherwise, individual timers are enabled. Users can customize the schedule with sudo systemctl edit uupd.timer.

Kernel Management#

Kernels are fetched from ghcr.io/ublue-os/akmods and all kernel packages are version-locked using dnf5 versionlock to prevent unexpected upgrades that could introduce incompatibilities. ZFS support is included for gts/stable streams via akmods-zfs with automatic module loading.

Variants and Editions#

Primary Variants#

bluefin: Standard desktop variant for general use.

bluefin-dx: Developer Experience variant with ~67 additional packages for development, including Docker, Podman, Incus, and LXC container runtimes, QEMU, libvirt, and virt-manager for virtualization, and VSCode, flatpak-builder, and git-subtree.

Both variants are available with standard graphics support (main) or NVIDIA GPU support (nvidia-open) using proprietary drivers with nouveau blacklisted and nvidia-drm modeset configured.

Bluefin LTS#

Bluefin LTS is based on CentOS Stream 10 rather than Fedora Silverblue and was built from the ground up on bootc technology, making it natively "bootc natural." It offers two kernel options: bluefin with the stock CentOS 6.12 kernel and XFS filesystem, and bluefin with the CoreOS kernel and hardware enablement modules.

Bluefin LTS includes containerd from EPEL by default and requires modern CPUs with AVX/AVX2 and FMA instruction sets (x86_64-v3 microarchitecture). The default firewalld configuration uses a "Workstation" zone with unprivileged ports (1024-65535) open for incoming connections while privileged ports remain blocked.

GNOME Testing Builds#

Bluefin LTS offers testing builds with different GNOME versions for early adopters:

GNOME 49 (default testing):

• bluefin - GNOME 49 with the stock CentOS kernel
• bluefin - GNOME 49 with the CoreOS kernel and hardware enablement

These default testing images use GNOME 49 packages from the jreilly1821/c10s-gnome-49 COPR repository with version-locked components to prevent mismatched upgrades.

GNOME 50 (parallel build):

Both bluefin and bluefin-dx variants are available with GNOME 50:

• bluefin - GNOME 50 with the stock CentOS kernel
• bluefin - GNOME 50 with the CoreOS kernel and hardware enablement
• bluefin-dx - GNOME 50 with the stock CentOS kernel and developer tools
• bluefin-dx - GNOME 50 with the CoreOS kernel, hardware enablement, and developer tools

The GNOME 50 variants are built through the full build pipeline using the GNOME_VERSION build argument, selecting packages from the jreilly1821/c10s-gnome-50-fresh COPR repository. These are experimental builds for testing the latest GNOME release on the LTS foundation.

LTS Build and Release Process#

Bluefin LTS uses a dual-branch model: main serves as the development branch, while lts serves as the production branch. Changes are developed and tested on main, then promoted to lts through a manual promotion workflow.

Branch Model:

• main branch: Development branch where changes are developed, tested, and receive automated dependency updates from Renovate
• lts branch: Production branch containing tested, stable releases published as :lts and :lts.YYYYMMDD tags

Promotion Process:

Changes flow from main to lts via the .github/workflows/create-lts-pr.yml workflow, which creates a promotion pull request. The workflow performs a regular merge (create a merge commit) from main to lts after running pre-flight divergence checks. Regular merge is used instead of squash-merge because squash-merge creates orphan commits that permanently break the merge base between main and lts, causing every future promotion PR to accumulate all historical commits in its diff. Regular merge preserves the merge base and keeps future PRs clean. The workflow includes a divergence check that blocks promotion if the lts branch contains commits not present in main, preventing circular history and git tree pollution.

All changes, including emergency CI hotfixes, must land in main first before promotion to lts—direct commits to lts are not allowed. A maintainer reviews and merges the PR (using "Create a merge commit," never squash-merge) as the human approval gate for promotion.

Build Triggers:

All LTS build workflows (build-dx.yml, build-dx-hwe.yml, build-gdx.yml, build-regular.yml, build-regular-hwe.yml) trigger on both main and lts branches:

• Builds on main: Triggered by pushes, pull requests, and merge groups for validation and testing
• Builds on lts: Triggered by pushes (including automatic merge commits from promotion) for production releases. Weekly scheduled builds (Sundays at 2 AM UTC) are centralized through a dispatcher workflow (scheduled-lts-release.yml), with individual workflow schedule: triggers removed to prevent duplicate builds

Dependency Management:

Renovate is configured to target only the main branch (baseBranchPatterns: ["main"]), ensuring automated dependency updates are tested in development before being promoted to production.

CI/CD Reliability:

The build workflows have been refined to ensure reliable image publishing:

• Tag pollution prevention: The manifest step logic aligns with the build step logic, checking if [ "${REF_NAME}" != "${PRODUCTION_BRANCH}" ] to apply the -testing suffix consistently. This prevents production tags from being overwritten by testing builds when merging to main.
• Manifest and signing fixes: The "Push Manifest" and "sign" steps are now properly gated on inputs.publish instead of github.event_name != 'pull_request', which fixes "image not known" errors that previously occurred when these steps fired on validation builds.
• Default publish behavior: The publish input in reusable-build-image.yml defaults to false for improved safety, requiring callers to explicitly opt in to image publishing.

SBOM (Software Bill of Materials) artifacts are generated only for builds on the lts branch when inputs.publish is true (condition: github.ref == 'refs/heads/lts' && inputs.publish). All SBOM steps include continue-on-error: true to ensure that external service outages (such as Sigstore/Rekor) never block image publishing. The sbom: input parameter has been removed from the reusable workflow.

Rebasing Between Variants#

Bluefin supports rebasing between variants while preserving the home directory, Flatpak apps, and configurations using bootc switch. Both system-wide Flatpaks (/var/lib/flatpak) and user Flatpak data/configs (~/.var/app/<app-id>) are preserved during rebase. The ujust rebase-helper command assists with rebasing to different variants.

System Administration (ujust)#

ujust is a command runner that provides system administration utilities for Bluefin.

System Management#

Application Installation#

Other Utilities#

Storage and Filesystem#

btrfs is included by default (unless HWE is enabled) and enables fast, space-efficient snapshots for backup. Bluefin LTS uses XFS as the default for bluefin with the standard kernel, while filesystem choice is available for bluefin. Bluefin LTS also includes bcache-tools for hybrid storage support.

ZFS on root is NOT supported in Bluefin, but ZFS support is available via akmods-zfs for gts/stable streams (data drives only) with automatic module loading configured.

Security#

Bluefin supports Secure Boot by default using custom Universal Blue keys with enrollment password: universalblue. Public keys are available in the akmods repository, and sbverify validates secure boot signatures during the build process.

All container images are signed with Cosign using SIGNING_SECRET and verified during builds to ensure supply chain integrity. Flatpak applications are sandboxed and TPM2-based LUKS auto-unlock is available via ujust toggle-tpm2.

Build and CI/CD Pipeline#

The build process uses a multi-stage container build with buildah/podman and rechunking using ghcr.io/ublue-os/legacy-rechunk for efficient updates. After secure boot signature verification and Cosign image signing, images are pushed to ghcr.io with retry logic.

Build Triggers#

Build workflows trigger on multiple events to support both development and production workflows:

• main branch: Builds triggered by push events, pull requests, and merge groups for validation and testing
• lts branch: Builds triggered by push events (including automatic merge commits from promotion) for production releases. Weekly scheduled builds (Sundays at 2 AM UTC) are centralized through a dispatcher workflow (scheduled-lts-release.yml), with individual workflow schedule: triggers removed to prevent duplicate builds

All LTS variant build workflows (build-dx.yml, build-dx-hwe.yml, build-gdx.yml, build-regular.yml, build-regular-hwe.yml) trigger on both branches to ensure changes are validated before promotion to production.

SBOM Generation#

SBOM (Software Bill of Materials) generation with Syft is performed only for builds on the lts branch when inputs.publish is true (condition: github.ref == 'refs/heads/lts' && inputs.publish). All SBOM steps include continue-on-error: true to ensure that external service outages (such as Sigstore/Rekor) never block image publishing, ensuring supply chain transparency for production releases without risking build failures.

Automated Brewfile validation runs in the CI pipeline, and GitHub Actions matrix builds handle variants and streams. image-versions.yml tracks SHA256 digests for base images, with version format: stream-fedora_version.YYYYMMDD[.point].

History and Development#

Bluefin was founded by three former Ubuntu/Canonical developers, including one who helped launch askubuntu.com, and represents "an interpretation of the Ubuntu spirit built on Fedora technology". The project philosophy emphasizes "Why spend decades documenting workarounds when you can just remove the problem entirely!" while rigorously moving away from legacy technologies and embracing cloud-native culture and tools.

In 2025, Bluefin underwent major architectural refactoring from a monolithic distribution to modular OCI containers with repo consolidation efforts. The project has grown to over 16,000 members on Discord with 123 individual contributors in six months.

All Universal Blue images share governance modeled after CNCF projects like Kubernetes with a lazy consensus approach: "Just Do It" unless problematic. The project is licensed under Apache License 2.0.

Usage Examples#

Managing Updates#

# Manual system update
ujust update

# Toggle automatic updates
ujust toggle-updates

Installing Applications#

Curated bundles:

# Interactive bundle installer
ujust bbrew

# Install Bluefin CLI tools
ujust bluefin-cli

# Install gaming Flatpaks
ujust install-gaming-flatpaks

Homebrew:

# Install CLI tool
brew install kubectl

# Install cask application
brew install --cask firefox

Flatpak:

# Install GUI application
flatpak install flathub org.mozilla.firefox

Rebasing to Different Variant#

# Interactive rebase helper
ujust rebase-helper

# Manual rebase to DX variant
sudo bootc switch ghcr.io/ublue-os/bluefin-dx:latest

System Maintenance#

# Clean up unused resources
ujust clean-system

# Factory reset (WARNING: erases user data)
ujust powerwash

Code Repository Structure#

Related Topics#

• Universal Blue - Parent organization providing base images and shared infrastructure
• Fedora Silverblue - Foundation for standard Bluefin variants
• CentOS Stream - Foundation for Bluefin LTS
• bootc (Bootable Containers) - Core update mechanism and image management
• rpm-ostree - Fallback atomic update system
• Flatpak - GUI application distribution and sandboxing
• Homebrew - CLI tool and package management
• Aurora - Bluefin's KDE Plasma sibling in Universal Blue
• Bazzite - Gaming-focused Universal Blue distribution
• uCore - Server-focused Universal Blue distribution
• GNOME Desktop Environment - Desktop environment for Bluefin
• OCI (Open Container Initiative) - Container image standards used for system delivery

See Also#

• Official Bluefin Documentation
• Bluefin GitHub Repository
• Universal Blue Documentation
• Ask Bluefin Community
• Bluefin Discord Community