Dakota Alpha 6 is out. This one is brought to you by Ahmed Ahdan/ Built against GNOME 51 and freedesktop-sdk 26.08.1, running Linux 7.2.6, NVIDIA 615.71.09. Kernel OGC 7.2.6-ogc1 for your gaming needs.

This one certainly feels good! Please remember that we still do NOT support secure boot, so temper your expectations! Here's the changelog, I'll make a video on this one since we have a lot to discuss!

Version matrix​

Alpha 5 baseline values are from tag stable-20260731 (as reflected in the Alpha 5 release announcement):

Note on kernel and bootc: Dakota pins its kernel at 7.2.6 via elements/core/linux-fdsdk.bst (ahead of freedesktop-sdk 26.08.1's default of 7.2.2) and pins bootc at 1.16.13 via elements/gnomeos-deps/bootc.bst (ahead of gnome-build-meta's default of 1.16.6).

GNOME 51 "A Coruña" was officially released on September 16, 2026 — see the official release notes.

Migrating Major GNOME Versions​

This is the first time we utilized dakota:next tracking a dev release, and Ahmed smoothly transitioned the testing branches through these:

Kernel and hardware​

Here's a bunch of enablement crap:

Desktop​

And some of the upcoming desktop improvements that we've been going over in the Discussions:

Game Mode​

Bluefin's "Game Mode" is fleshed out now, offering access to a "Bazzite Light" gaming setup, perfect for slaying out. Destiny on Linux please Sony!

Image and boot plumbing​

The chunka work is great, you'll notice way smaller updates than the old images. Top of the line hunter!

Behavior changes​

• Ghostty ships resize-overlay = never; theme tracks the GNOME Dark/Light preference.
• snd_pcsp sink disabled in WirePlumber — audio no longer falls back to the PC speaker after resume.
• zram is disabled; swap is zswap backed by /var/swap/swapfile.
• Bluetooth-Battery-Meter is replaced by BudsLink-Companion plus the io.github.maniacx.BudsLink Flatpak.
• aarch64 images are not published this cycle. (We'll turn these on soon)

Images​

You can't rebase to Dakota from another image. If you're not on Dakota already, reinstall from the ISO.

ISO downloads​

• Dakota Alpha 6 ISO
• Dakota Alpha 6 Checksum
• Latest Dakota daily snapshot

Testing instructions and bug reporting: ISO Testing. File ISO bugs in projectbluefin/dakota-iso.

Lore​

Remember that the wolves are coming, level up your skills at training.projectbluefin.io. It's a tough world out there, here's a sneak peek at the artwork from the artists at makemeacomic.com! These are just a sample of entries from a mysterious journal uncovered on Europa by a [REDACTED] merchant. Inside are the secrets to unlocking the potential of Contributor-Guardians and their mounts. But the forces of the Toilmaster are already ahead of them. Instructions from a doomed CNCF Expedition are sparse:

Click to expand

‹›

1 / 4

Bluefin

Long-Range Raptor Mount

BluefinQuetzalcoatlusTriceroBrachio-Trax

Bluefin — Long-Range Raptor Mount

✕

‹›

1 of 4Open full resolution ↗

Model Context Protocol (MCP) is an open protocol for LLMs and agents to talk to each other. We're now serving the Project Bluefin organization knowledge base and live factory state at https://mcp.projectbluefin.io/mcp.

Right now hive.projectbluefin.io exposes an API that has things that are useful for agents. We use it to dole out work to volunteers and to get review tasks. This is what's letting us scale out in ways we haven't been able to before. Hive has a nice Knowledge Base that it exposes, so this initial cut is to search that knowledge. This is mostly useful to connect whatever agent you use to our stuff and get context for your agent. So if you want to do Bluefin things you just add this. I've updated the Agentic Contributor Guide, note that our hive API endpoints are published, so if you're building a deep integration it probably makes sense to work with the Hive API directly. Feedback and usage notes welcome!

Endpoint Details​

• URL: https://mcp.projectbluefin.io/mcp
• Transport: Streamable HTTP / Server-Sent Events (SSE)
• Authentication: None (public, read-only)
• Health Check: https://mcp.projectbluefin.io/health

Available Tools​

Here's what's exposed:

Related Reading​

• Why Bluefin is all in on agentic development
• Bluefin's Sausage Factory
• The Future of Bluefin - Time to be Honest
• Bluefin: Welcome to the Jungle
• Agentic Contributor Guide

wolves.projectbluefin.io​

A follow up to The Future of Bluefin - Time to be Honest.

Alright everyone we've heard the feedback. You'd like to press X to pay your respects and get to work. Start the Q+A please!

Earlier this month Ahmed Adan and the rest of the Dakota team worked to bring the Open Gaming Collective kernel as an option for Bluefin's new "Gaming Mode". These kernels are explicitly designed to ship greg k-h's kernel and only ship patches that have a path upstream.

Here's some context:

• ghcr.io/projectbluefin/dakota-gaming:testing (and stable)

• ghcr.io/projectbluefin/dakota-nvidia-gaming:testing (and stable)

• Gardiner Bryant's Coverage

• Bazzite Announcement

Jorge Castro 🇵🇷 🦖@castrojo.bsky.social

Three years ago today. Nova they won't let us down, I promise.

Aug 17, 2026, 3:18 AMView on Bluesky

Guardians ... a new Dakota arrives, likely our last before beta. @ahmedadan brings us an example of the power we can wield with BuildStream and The Final Shape. (Ask him about his COSMIC image!)

The builder is back in business and we now have enough institutional knowledge to make getting a new one and swapping it in easier. Improvements in the tooling in general has helped. And my homelab is doing from-source builds in 8 minutes, that's 4 minutes faster than assembling RPMs. We intend to make it trivial for anyone to deploy these on any modern infra. Buildstream and Kubernetes is a beautiful thing.

The world has changed! Here's the good stuff.

What it comes with​

First let's get the versioning out of the way. Since we're based on freedesktop-sdk project we'll use their version. In this case, 25.08.11. The 11th release of the August 2025 major update. 26.08 is our next update. Yes, that's next month. :) Bluefin will remain versionless and tested as a whole, you'll just switch aggressiveness with game mode if you want:

• Kernel: 7.0.11
• Game Mode Kernel: 7.1.4-ogc1
• GNOME Shell: 50.3
• freedesktop-sdk: 25.08.11
• bootc: 1.16.6
• systemd: 260.2
• Flatpak: 1.18.0
• :testing GNOME 50 development builds
• :stable Publishing daily if tests pass, moving to every other day for beta, weekly for GA
• :next GNOME 51 rolling builds, currently busted.

We're helping out GNOME OS by shipping a new zswap configuration, based on their inprogress work upstream. Dakota uses zswap backed by a disk swapfile, rather than zram.

• zswap.enabled=1 keeps recently swapped pages compressed in RAM, avoiding disk I/O when they are needed again.
• zswap.compressor=zstd selects Zstandard: generally a good compression-ratio/CPU-speed balance.
• zswap.max_pool_percent=20 caps the compressed RAM pool at 20% of installed memory.
• zswap.shrinker_enabled=1 lets the kernel reclaim zswap memory under pressure by writing colder compressed pages to the backing swapfile.
• vm.swappiness=100 makes the kernel treat reclaiming anonymous memory to swap as comparable in cost to reclaiming file cache. Since zswap absorbs the initial swap writes in RAM, this aims to preserve filesystem cache without immediately incurring disk latency.

The backing store is /var/swap/swapfile, created on demand at min(RAM / 2, 8 GiB) when the disk is large enough. Dakota explicitly disables GNOME OS's zram device, so it does not stack zram and zswap; The kernel arguments live in /usr/lib/bootc/kargs.d/20-zswap.toml, so bootc applies them on image switches and upgrades.

Feel free to give feedback on the swap stuff, it's an exciting area where we can hope to help out GNOME!

Open Gaming Collective​

As part of our mission to improve the Linux desktop we're offering a "Game Mode" to Bluefin, which will pull in a bunch of stuff. It will be available in a checkbox in the control panel and is basically a lightweight Bazzite-lite built with BuildStream.

Yes, an OGC gaming kernel with aggressive updates but at least upgrades will work, lol. It will slay, so it is also aliased to dakota:btw. For the discerning raptor rider.

• The kernel includes gaming-focused patches/features, including sched_ext and ntsync
• Steam and its 32-bit compatibility libraries and controller udev rules, etc all built in - this is basically the Steam flatpak, you'll show up as "Freedesktop" in the Steam Charts
• Gamescope and the Steam Big Picture gamescope session
• GameMode, MangoHud, and vkBasalt for performance management, metrics, and post-processing.
• InputPlumber, SDL controller database, and handheld/controller support. Note that we don't support handhelds but shrug it's all Linux.
• All that extra Vulkan, SDL, audio, X11, USB, and input compatibility libraries for native games and stuff. Shout out to Kyle Gospo for the guidance!
• First-boot Flathub installs for Lutris, Heroic, Bottles, ProtonPlus, Protontricks, and GOverlay.

And I'm sure I missed some.

How to Get It​

There will be a GUI for this soon, in the meantime enjoy! You can't rebase to this from another image, if you're not on dakota already you need to reinstall.

ISO Downloads​

• Dakota Alpha 5 ISO
• Latest Dakota daily snapshot

If you want to understand how a modern Linux distribution is made, you eventually have to look at the "sausage factory" - the intricate pipeline of code repositories, build systems, test suites, and orchestrators that turn raw source files into something you can boot on physical hardware.

Supakeen posted The Fedora 45 Sausage Factory, and the curtain was pulled back on Fedora's use of dist-git, Koji, Bodhi, Pungi, and openQA to make Fedora.

People are asking "what's the equivalent of this in Bluefin?" Most of this stuff sounds like a Pacific Rim sequel, so let's take a look. We are currently in the process of moving away from our own legacy sausage factory to Bluefin's final destination: Kubernetes.

• projectbluefin/common: The shared "org brain" containing system configurations, desktop defaults, documentation, and foundational OCI layers. When most of you think "Bluefin", it's in here.
• Image repos (bluefin, bluefin-lts, dakota): Derivative image definitions that consume common and layer specific desktop experiences or lifecycle variants.
• Instead of spec files and tarballs, Bluefin's definitions rely on Containerfile directives and declarative package manifests. But in some cases you may still find a vestigial inline package install in a script.

Under the Hood: The OCI Toolchain​

I've read comments on Reddit that think that all of this is GitHub-specific. GHA is there because we're lazy. At the end of the day, all of Bluefin is locally buildable on any service. And on any OS: you can build Bluefin on Macs and Windows too. Each repo has its own Justfile covering different tasks.

The entire point of cloud native is that you should be able to build the thing anywhere. If you get confused by "cloud native", try to remember "API Native" instead. Let's look at some standard OCI things:

  [ git ]                [ buildah ]               [ podman ]                 [ skopeo & bootc ]
Declarative Config  --->  Daemonless Layer    --->   Local Execution     --->   Registry Transport
& Tracking               Composition                & Inspection               & Host OS Deployment

• git: Tracks everything. This is the single source of truth. This is called declarative config and has all the config files.

Linux distributions talk about "rolling vs. stable" - this doesn't make sense in modern Linux. The entire thing is a git branch. It's what you choose to ship.

You need to ship the entire git branch. That means releases AND rolling tags, feature branches, testing branches, "test this crazy thing here temporarily branches", all of that. git is fully open source and not under the control of any single vendor. When the Bluefin factory is cooking things that used to take months now take hours:

• buildah (Daemonless Builder): Assembles container layers statelessly without requiring a background daemon or root privileges on host runners. buildah is a CNCF Sandbox project and not under the control of any single vendor.

• podman (Local Validation): Enables local parity. Developers can run podman run locally to inspect built layers before pushing code. podman is a CNCF Sandbox project and not under the control of any single vendor.

• skopeo (Transport & Tags): Handles low-level OCI manifest operations - copying images directly between registries, inspecting layers, and managing release tags. skopeo is a CNCF Sandbox project and not under the control of any single vendor.

• bootc (Target Deployment): Bridges standard OCI container images directly to the target machine's disk. It handles kernel handoff, transactional filesystem updates, and automatic rollbacks. You're not going to believe it ... bootc is a CNCF Sandbox project and not under the control of any single vendor.

Practical Walkthrough: Adding an Application​

Let's add a new application. Let's say the control panel we've all been missing. Brian Ketelsen, Father of Bluefin and now control panel connoisseur has blessed us with this:

He's been rolling with this in his custom image. And if you're like me you probably want that thing right now. Here's the Git repo. Not distribution specific either, Brian's images are based on Debian. See how weird it is to classify things the old way? Who cares. It doesn't even ship on the image it ships in homebrew lol.

In Bluefin, adding an application comes down to choosing where the change belongs in the repository tree:

Option A: At the Shared Level (projectbluefin/common)​

This is 95% of it. Someone saw a new app in Flathub and wants to feature it, or we need to swap out a component when an app gets deprecated, etc. Chairlift will go here.

• Contributor: edit a central Brewfile (for Homebrew CLI utilities or Flatpak desktop apps).

Option B: At the Image Level (bluefin, bluefin-lts, dakota)​

• Contributor: edit an image-specific build script (e.g., build/10-build.sh executing dnf5 install -y <package>) or a bst definition file.

This is usually system-level stuff, or may be things the user doesn't see that we deal with. For example, NVIDIA drivers on all three are installed differently. Or if your hardware acceleration breaks, etc. Anything that touches the metal, like that OGC kernel.

Change Processes​

We have a lazy consensus model - in the early days of Universal Blue we had full-blown specs and it looked similar to what you see in Fedora today. These days you can file a bug in common and if maintainers have consensus, we do it.

This can cause friction for new users who do not understand Bluefin's mission. An open process doesn't mean a free-for-all. It also means we force work OUT of the org. For example, in Dakota we'll be prototyping zswap configs, but -

However, the entire process is in the air. Six months ago I would have told you, "if you didn't file a bug, I don't care; you didn't put in any effort, so I won't either." Now I can point an agent to my entire Discord and slurp out months of people's actual bugs and get actionable feedback.

This is why IMO the best thing we could invest will be ujust report. We make it easier for people to submit their technical data, opt-in. But that is a post for another day!

Two Eras of OS Engineering​

Fedora's sausage factory is a masterclass in classical Linux release engineering. But we are a small project and cannot afford such complexity.

And then you would say, "But Bluefin is Fedora/CentOS, you can't make Bluefin without it." And you'd be right! And then the other half of the room would say, "Listen to the k8s guy talk about complexity!" And they would also be right!

The last bit is BuildStream, which effectively replaces just about everything in that Fedora diagram with a single, simple CLI tool. BuildStream is hosted at the Apache Foundation.

The Final Shape

Shove your Linux dreams in git​

If you're a developer, the entirety of your existence lives in git.

• Anything you want, any version you want, we're going with GNOME OS versions first
• But then add things like OGC kernels, nicer Mesa, etc. We're finishing up the Dakota gaming image now and there will be a nice GUI to make all of your lives happier.

This is GitOps, so forking, etc. is encouraged. Pretend you can get a Bluefin for every possible iteration (because you can!) Some of you will think this is about images, but most of you will do the smart thing and swap out Brewfiles and "top 10 kickass Flatpaks" and so on. Both of these ecosystems are distribution-agnostic.

A vendor-neutral, well-maintained toolchain makes your dream real​

You know when I say "distroless", "cloud native", "the Kubernetes moment", and all of that stuff? And then people laugh? This is what I mean. Moving away entirely from the concept of distribution tooling to commodity tools.

It's down to git, bst, and bootc. BuildStream can output your dream in one go. THE ENTIRE MIDDLE PART GOES AWAY. No intermediary format - it goes right to a format that we can run tests on, scan, etc. You don't need "distro builders"; you just need normal containers!

I could give a sysadmin these three tools and a laptop with the right creds and publish Bluefin, and none of you would notice.

The DevOps Part​

So on the one hand, we have The Final Shape. It's clear what I think: we optimize for correctness in Linux first, your shitty VPN RPM be damned.

What Fedora Hummingbird brings to the table is to take all of that operational knowledge Fedora has, and then bring THAT into the container-native space. They are, after all, building a Linux distribution.

Which is also why we say we're not a Linux distribution. Dakotaraptor was born into cloud native. It will never have to deal with COPRs or akmods or any of that stuff. It will just have what it needs with a handful of tools and infrastructure.

I would argue our appeal is that we start from the success of Kubernetes. I have now experienced BuildStream with Buildbarn and Kubernetes.

• From a technical perspective, it excels at everything we need it for and I have yet to see anything even in the same ballpark.
• From a cost perspective, it's unbeatable. Every infrastructure provider in the world sells K8s, and everyone's laptop has podman.
• Contributors

That last one. Millions and millions of developers know this tooling already. This is a great opportunity to meld the distribution processes with new people coming in at Hummingbird Factory level.

Our message to contributors remains the same. Use the tools everyone else is using - bias towards trusted vendor-neutral organizations. I have annoyingly pointed out which of these tools are hosted by the CNCF and the Apache Foundation. This is what "Cloud Native Linux" is.

This is not a dunk​

I liken Fedora to last year's McLaren. When it comes to traditional Linux distros, you'd have a tough time beating Fedora. And just about everything you hate about it has nothing to do with the tech and probably the policies.

This is why Fedora Hummingbird's factory is appealing to me. As you can tell, I can't shut up about it.

But things change, and every year the users demand the spectacle. Fedora Hummingbird is a ton of well-funded enterprise tech - they've got wind tunnels, an awesome factory, engineers fighting to be the best. Inserting all of that Fedora operational DevOps knowledge into a modern Hummingbird design would slay.

Fedora Hummingbird is built with this same collection of CNCF and Apache projects. Combined with other open source projects, many of which are controlled by a single vendor, but have years of enterprise pedigree with billions of dollars worth of ecosystem to show for it.

We should encourage this, all in the name of sport! Sharing about 95% of the tooling and the people. Let's not forget that Ubuntu's putting in some great laps!

Is AI good or bad for open source? This is 58 minutes of me explaining what I've learned on this.

If you're here for the hot take: Are we really all on the same side? There are two worlds in Linux. What reddit/masto/youtube thinks "Linux" is. And then how Linux actually is.

Our value to our users is that we give you Linux as designed by the professionals. The flex is leveraging the collective knowledge of the community. New users have been led to believe that shipping three-year-old kernels and old software is the right way to consume Linux. Good luck with that. When it comes to my Linux, we listen to Lennart. We do listen to GNOME developers. Linux is about choice. We choose a well-designed system and thank the UNIX gods every day that we don't have to deal with that stuff.

We choose not to let people dictate to us how to use our computers. The science is out. The experts have spoken. I've been fortunate to have access to Greg K-H during his time, and we spent a long time discussing how this affects our communities. And he's right. The damn things are finding bugs. And I'm tired of Linux's bullshit. And I mean that in a loving manner. 90% of this crap is passing a 0 or 1 to some silly argument because Asus hates you.

We've got new territory to explore and we're moving quickly. My lesson from six months of AI is "Seven Days to the Wolves". Where will we be when they come? I've been doing this job a long time and it took me fifty-eight minutes of Puerto Rican mansplaining and a cloud-native symphonic metal musical to explain it. LOL.

First let's celebrate. It's five years of Bluefin and Universal Blue! Thanks for riding with us. Starting later this year you can join Bluefin, Rafael, and the rest of cloud native as Bluefin comes to your hands.

We're proud to announce Seven Days to the Wolves, a comic and musical series set in an alternate future where Maintainer-Guardians fight alongside users for survival. We hope to expand this into the world's first cloud-native musical to be performed live at KubeCon (We have goals!).

In the meantime, enjoy this multi-hour metal maelstrom of death and destruction. #stopjohnbazzite

BLUEFIN: SEVEN DAYS TO THE WOLVES​

Will you be ready when they come?

Parts of the story will be dropping over the next few years and will star some of your favorite OSS heroes!

The Great Migration​

We're in the process to moving to the factory to build Bluefin. This process is opt in and will be a transparent to most of you. The TLDR is you'll see your image name change from gchr.io/ublue-os/bluefin to projectbluefin/bluefin.

It's midsummer so not a bunch of changes on the images. We'll work on this in 2H2026 so for now there's no need to worry, just chill and enjoy your Linux!

Bluefin​

Let's start with Bluefin.

The new Bluefin is a tad smaller. We're dropping the dedicated DX images, everything we support is in brew now and is operating system agnostic. We aim to ship the most popular developer environments in cloud native and hope you give us feedback on things. ujust devmode is the CLI and remains unchanged.

Don't expect many changes here other than moving to sealed images at some point. projectbluefin/bluefin:next is in place if anyone wants to start working on that.

Anyone who is interested in driving forward with the Fedora base images is encouraged to work here. This is also the first time this Bluefin has an aarch64 version!

• Bluefin Repo

Bluefin LTS​

Bluefin LTS has also moved over to the factory. Bluefin GDX users have been moved here already. Nothing to report, though we turned off the ISO downloads to the old versions so people don't get confused. Once everything is set here we'll relaunch new ISOs.

Not much to say here, I'm mostly here for the fuzzy brown guy. Bluefin GDX has been retired as an image, the proper Nvidia tools are on the nvidia images themselves, and most of what was "GDX" is now in userspace with brew and containers, enjoy!

• Bluefin LTS repo

Dakota​

Dakota is our latest and most sophisticated raptor, featuring the cutting edge of Linux desktop development. It's built from GNOME OS using BuildStream.

Most of the work I've been involved with this cycle has been working on this. (And failing lol). Ahmed and Jordan just got the builds online and we'll probably do another alpha later this month. Things are really great here and I spent some time with the GNOME OS and systemd folks in Berlin this summer to ensure we're on the right track.

James and I worked on the ISOs this cycle, and we finally have one unified ISO that covers Nvidia/AMD/Intel on one ISO. Needless to say this is my raptor of choice and I'm hoping to play with more builds this weekend. Once the builders are up I'll start work on Bluefin's "game mode", offering the very best of OpenGamingCollective's tech.

• Dakota repo

Bluefin and The Forbidden Factory​

The "factory" is a culmination of everything we've been building. I guess it'd be the equivalent of "Universal Blue 4.0". It's simultaneously the most important change in Bluefin's history, and the most invisible! Also spoiler alert it's the second comic!

It's a combination of the server OS, FSDK containers, Kubernetes, Argo, BuildStream with Buildbarn, and everything you need to build Bluefin "on the spot". Basically, instead of "the OS" consider the entire toolchain "the product". Unlike the old methods, this new factory is all about leveraging clankers and putting them to work effectively via hive.

The Factory is a result over about a year of convergence with many groups. We've assembled GNOME 50 desktop tests and have started work on KDE. We test everything in this thing. Each test runs through a full suite. Checks everything, network, apps, and other functionality. We can finally automatically test everything and then post a screenshot at the end of the test.

And not just Bluefin. We're throwing everything at this thing. Aurora, Bazzite, Fedora Silverblue, Zirconium, GNOME OS. Every time there's a published image we run a battery of tests on it. We are not yet doing visual recognition - this is to catch visual regressions. Right now we're just hoping someone on a testing build is paying attention. It's encouraging to see members from bootc and the UAPI Group working in this space. The idea is to have a completely manageable, reproducible, and sovereign system to run everything, not just a few desktop images.

The Factory dashboard is one of the best ways to see whether an image is actually ready to ship. This is meant to expose more broken things before they reach you. Check out the Hummingbird public meeting this Thursday, where I hope to present on the components in more detail!

I'll also be doing a complete factory tour and explaining our experiences with agentic development. I look forward to moving faster here! I spent a good deal of time on the charts:

The dashboard is live, so those numbers will move after this post ships. The Factory dashboard and its underlying data are the sources for this snapshot. We'll continue to add information here over time!

Freedesktop SDK Containers (Alpha)​

Every factory needs purpose-built containers. Since the goal is a fully offline, self-contained build system, we built our own — carved from freedesktop-sdk components using the distroless playbook. 90% of "distroless" is deleting all the docs and not providing shells. We're able to do this quite easily with BuildStream

The current images range from a ~40 MB distroless base (glibc, coreutils, CA certs, tzdata) up through distroless Python, Buildah, and Skopeo variants. I also made an omnibus lab-runner with kubectl and a few other tools in one convenient package and a shell for ops work. Two prototypes are worth calling out:

Homebrew nspawn container — a Homebrew developer environment packaged as a systemd-nspawn machine image rather than an OCI image. The systemd folks think this approach is worth investigating, and this is the result of some beer drinking in Berlin. I haven't tried it yet but if you're one of those distrobox-adjacent folks it might be interesting for you.

All images are keyless-signed with Sigstore Cosign and include BuildStream-native SBOMs. Tags track the FSDK point release. The actions are easy to copy — fork and go, no key wrangling required. I am finding the base images to be quite good, and in general I find the fsdk containers to be a nice alternative to Chainguard and other distroless images. For us the benefits are simple, these are the same libraries as the operating system so it doesn't cost us much to make these.

• fsdk-containers repository
• Release v25.08.13
• Discussion thread

Bluefin Server (Alpha)​

Bluefin Server v25.08.13 targets the same space as Flatcar Container Linux, Fedora CoreOS, and Talos — but is built from scratch with BuildStream 2 from freedesktop-sdk components. This one was kind of an accident. I needed a server OS for the new homelab and there wasn't an easy way to get a newer kernel in Flatcar. Since we have BuildStream, making this was pretty straightforward. This is basically the Dakota setup without the desktop.

The OS payload is a compressed XFS DDI filesystem deployed by an offline, systemd-native installer. This is using systemd's new interactive installer. Burn it to disk and run through it and then you're done.

Key properties:

• DDI image-based updates with atomic rollbacks via systemd-sysupdate
• Minimal, distroless rootfs — going to shoot for no shell by default with a GUI but we'll see how far we get on that
• k3s for kubernetes available as a systemd-sysext
• GPG-verified SHA256SUMS, BuildStream-native SBOMs, keyless signing throughout, all that crap
• Currently on the GNOME Desktop kernel but I am shopping around, since we're using UKIs swapping out kernels is easy

Alpha 1 is live. Beta comes after the 26.08 FSDK bump next month. KubeStellar dashboard integration is in progress but not ready yet.

• Bluefin Server page
• Server repository
• Alpha 1 release
• Discussion thread

Testsuite: Full Desktop and Image Coverage​

Bluefin's automated test suite is the quality gate between an image build and promotion. It runs headless Wayland desktop sessions in QEMU on standard GitHub Actions runners and can be supplemented with any hardware.

What it covers​

Here's what we've got working on so far. Shoutout to Christian Schaller at Red Hat for guidance:

• smoke — core GNOME, Settings, MIME handlers, accessibility, desktop identity, Orca, input methods, keyboard layouts, XWayland, ScreenCast, screenshot portals, Online Accounts, and printing
• common — portable SSH health checks for Flatpak, portals, polkit, shell behavior, immutability, and system health
• vanilla-gnome — upstream GNOME OS baseline
• developer — Homebrew and Ptyxis on developer variants
• dx — VS Code, distrobox, JupyterLab, and mise
• software — Bazaar app-store behavior and Flatpak CLI health
• lifecycle — bootc upgrade, rollback, and migration
• security — Cosign signature verification
• hardware — udev rules and emulated peripherals
• bazzite — Bazzite-specific extensions
• flatcar — Flatcar OS boot and lifecycle

The smoke and common suites are designed to run against any GNOME bootc image so feel free to take it for a spin.

How it works​

• Behave runs the Gherkin scenarios and step bindings
• qecore-headless bootstraps the Wayland and D-Bus session
• Dogtail drives the accessibility tree through AT-SPI
• gnome-ponytail-daemon provides coordinate injection for Wayland
• GNOME Shell Eval handles the GNOME 50+ top-bar fallback
• Shared SSH steps assert system state from outside the VM
• Dynamic suite sharding distributes large smoke and common runs
• Coverage counts and screenshots publish to the Live Build Health Dashboard

We'll continue to expand it as some tests are better than others.

Reusable integration​

Image projects can call the reusable e2e.yml workflow or the gnome-e2e@v1 composite action with an OCI image, selected suites, a test ref, optional native-app skipping, Flatpak screenshot IDs, zstd:chunked coverage, VM memory, CPU count, and disk cleanup. The suite also provides reusable ISO validation for downstream projects. None of this has been tested outside of myself so if you're diving in get ready to get dirty!

Local development uses Python 3.14 with behave, qecore, and dogtail; full GUI runs require a live Wayland and AT-SPI session. The repository includes Argo and KubeVirt plumbing, a coverage dashboard, Codecov reporting, Flatpak caching, and the container images used by the test jobs. (The whole enchilada!)

Successful run · 4 / 0 / 4Failed run · 3 / 1 / 4

Does this mean I'll get less bugs?​

Yes and no. Most of these aren't blocking yet. A few of them catch issues you've reported in old-bluefin. Some of them give us capabilities we've never had, like mass upgrade testing.

If we had perfect Linux tests no one would ship because the entire desktop stack is a tyre fire lol. However with better, more automated testing we can get to where we need to be!

Suncatcher​

Bonus wallpaper from Natalia and Delphic!

The Lab, Actions, and Finpilot​

projectbluefin/lab is the "everyday" part of the lab. It contains everything I am running in the homelab to test Bluefin, etc. It runs image and ISO tests in KubeVirt, handles graphical checks on the lab hardware, and collects screenshots and results that can be attached to a build. That lets us validate the thing people actually install, not just the container build that produced it. These tests are additive and listed on the website.

We're adding these as gates, which means when a contributor merges something it will land in a testing branch. Then as part of the release processes all of these tests run. The lab repo is for people who want to add their homelabs to help with Bluefin. It's messy in there, but if you know K8s, help is always wanted!

The intent is for these to be driven by GitOps, which means no access control or people connecting to remote servers, your agent either opportunistically finds work or is assigned work from hive. Lab repo

projectbluefin/actions is the shared build layer behind the factory. Repositories can use the same workflows for bootc image builds, multi-architecture publishing, signing, SBOMs, and release metadata instead of each project inventing its own supply-chain plumbing. This is the sort of infrastructure that is invisible when it works, but it is what makes the rest of the factory repeatable. These actions are all new and heavily centralized, so if you want your custom image to use the latest tech, check out this repo.

finpilot is still there and now has a new maintainer! This hasn't been integrated into the factory but it's working pretty great. finpilot repository

Merch​

The Bluefin store has a couple of especially good ways to rep Bluefin. All of the proceeds go towards artwork, and the kid's shirt is priced the lowest we could make it.

Dakotaraptor Forever

Celebrate the stable release of GNOME OS in the official Dakotaraptor shirt.

Shop the shirt - from $23

Bluefin Official Shirt

First among equals, the leader of the pack, in a soft everyday tee.

Shop the shirt - from $25.50

Bluefin Women's Rawr

Stabby stabby stabby - a relaxed-fit everyday tee with a little more raptor energy.

Shop the shirt - $16

What's next​

The 26.08 FSDK release is next month and Dakota's looking to move to beta so there's plenty to do. In the meantime enjoy your day and rock out to some Wolves metal! Then we cycle into Fall.

As always thanks for joining us and keep on rocking! Feel free to ask questions, we covered a ton!