Greetings Guardians!
Today we're going to go over some of the things we're finishing up for 2025, and talk about where we're going in 2026. Check out the Autumn 2025 Update and the 2024 update if you want more backstory. We appreciate you joining us on your Linux journey, let's get going!
Companion Video if you wanna check it out!
Also check out:
How was 2025?#
This year we spent most of our time on cleanup and sustainability. Bluefin is mostly feature complete so we don't really ship major user-visible changes as much as we used to. Much of it is "nerd automation" improvements that most of you will never need to actually care about. This has also been a kickass year for Bazzite, which has been a fantastic real-world test for bootc based sytems like ours! Overall the ecosystem is doing well, this year was great for bootc, here's a photo of the team from KubeCon this past November:
Jorge with members of the bootc team: Mark Russell, Joseph Marrero, Laura Santamaria, and Colin Walters
We continue to sync with the various teams at Red Hat as we journey with bootc through its CNCF Project Lifecycle. This works out well for us because we know what we need to do. Our role is to provide an independent voice, and with new orgs like the bootcrew, bluebuild, and secureblue springing up it brings more voices to the choir. 2026 will be the year where we expect participation in bootc to increase. This is also why you've seen us slowly decouple from Universal Blue more explicitly. This is a forcing function to move us away from monolithic "distributions" to an ecosystem full of different images, each with different communities and needs, while retaining the value of shared components.
As you'll soon see below, we can source software from anywhere and it's just a bunch of containers. This is reflected in our use of @projectbluefin as our new main GitHub org as we strive to move further away from distribution specific tooling to a cloud-native world.
But that sounds like a bunch of marketing crap, let's explain it ... this update will cover mostly "How Bluefin is made" and where we're hoping to head in 2026.
JF's Bluefin desktop
Tracking Progress#
todo.projectbluefin.io will send you to the project board. Every item in this post will be tracked here. Some of the things in this post are complete, and some are close and need help, feel free to dive in!
You may notice some minor changes (like the motd colors changing), but we're hoping to be complete with the major transitions over the next two weeks. File an issue if you notice something! Exercising the fix-loop with this new architecture will immediately show dividends as we can now ship fixes to all Bluefins and Aurora.
We've also updated the Contributing Guide to reflect Bluefin's updated architecture and processes. Note, Linux nerd stuff incoming:
Architecture Overview#
Bluefin is undergoing a refactor with some significant changes under the hood, which we expect to finish soon, but is mostly there. Some of this isn't done yet, so I'm going to talk about the endstate of where we want to be. Bluefin is a combination of a set of configuration OCI containers which are then shipped on different images. Originally the Bluefin repository had everything we needed, and was a result of organic growth. Everything was built here.
The team drastically refactored this repository in 2025 since it predates the usage of bootc and was falling behind. Similarly, Bluefin LTS was built from the ground up on bootc, but we had to manually bring over the Bluefin parts to build it. We want to share as much code with Aurora and Bazzite as we can. The three projects share many things, but we needed a more efficient way to do this. "One big Bluefin" wasn't going to cut it. So we rearchitected Bluefin to the following model:
Bluefin OCI containers#
These are what make up the bulk of Bluefin and are shipped as OCI containers. This moves us away from classic distro packaging and towards a pure cloud native approach. We're migrating away from the packaging repo and instead keep all the config files in an easy-to-read tree in git, that just gets copied over in the build step:
- @projectbluefin/common - Most of Bluefin's opinion on distro experience is here
- ujust, motd, service units, GNOME and CLI configuration, application choices, etc. Most things that have to do with the workload should live in this repo
- This is shared with Aurora so that we can maintain consistency across images
- @projectbluefin/branding - Branding assets that we don't want to keep in the common repo
- @ublue-os/artwork - Art assets repository, shared with Aurora and Bazzite
- @ublue-os/brew and associated @ublue-os/homebrew-tap - these provide homebrew itself and our selection of custom brew packages. This also simplifies adding homebrew to custom images. Thanks to those of you who have been helping homebrew be better on Linux, it's amazing!
These containers have the advantage of making consumption by other bootc projects trivial and are (mostly) distribution agnostic. Custom images now have a granular option to pick and choose the components they want to ship instead of dealing with one monolithic experience. We've structured the common repository to be extensible, here is how Aurora does it for reference. This allows the team to keep configuration centralized while allowing endpoints for custom builds.
Final assembly...#
Once we've established a set of re-usable components, we then combine them with a base image that make the final operating system:
- @ublue-os/bluefin - Bluefin: generates a Fedora-based Bluefin OCI container
- @ublue-os/bluefin-lts - Bluefin LTS: generates a CentOS-based Bluefin OCI container
- @projectbluefin/distroless - Dakotaraptor prototype - generates a GNOME OS based Bluefin OCI container (more on this below!)
Since the bulk of what makes Bluefin is now just an OCI container the base OS can more easily be abstracted away. This means that these repositories can now do way less than they were doing before. We will continue to prune these over the course of this year.
A Streamlined, Maintainable set of Images#
Decoupling Bluefin this way has already allowed us to delete a bunch of duplicated code, and makes maintenance easier for the team. This also makes it way easier for people to contribute and resolves a bunch of parity bugs between the images. Maintaining Bluefin happens in the common OCI layers and not as much in the image repositories. Custom images will start moving this way too as it let's custom image builders pick and choose from whichever container they want at a much more granular level.
This also gave us the opportunity to clean up a bunch of old justfiles and scripts that have not been looked at for years. Our new justfiles are much smaller and more maintainable. We also took the time to add confirmation dialogs and other quality of life features in there. We have also been taking a less-is-more approach by shipping less customizations as just recipes.
Thanks for your patience with this transition, it did take longer than expected but we took our time since we're planning on long-term maintenance first. This is the smallest that Bluefin has ever been!
Looking forward to 2026#
I had to explain how Bluefin will be built in order to explain the changes coming. These are the user-visible changes that you can expect in 2026:
Bluefin#
As covered in - Streamlining Bluefin Releases we will be merging the bluefin:gts images into bluefin:stable. Effectively we're merging them both.
We wanted to commit to a date as soon as we could, and will be moving you to a Fedora 43 base that week. And then everyone will be upgraded to a Fedora 44 base about a month later. Note that this won't be a zero-day upgrade and will follow the usual CoreOS cadence. By then the next -> testing -> stable workflow will be live and you'll be able to opt into the newest versions at your leisure. If this is confusing to you don't sweat it, we'll be more communicative when March rolls around to keep the transition as smooth as we can.
This will also be this single most user-affecting change in Bluefin for 2026, and we're really looking forward to having a proper gitops workflow with testing branches!
Bluefin LTS#
Some of you may have noticed parts of GNOME 49 landing in Bluefin LTS. Originally we had planned on backporting GNOME ourselves but this is happening as part of CentOS Stream's lifecycle. This "feels" like a good cadence for an LTS. Here's the lowdown on where LTS is today:
- The tuned policy still needs a fix, this makes you have to run a workaround to get power management working on a laptop. This sucks
- Many of the inconsistencies will be resolved once Bluefin LTS moves to the common OCI layers
The hardware enablement branch brings in the Fedora kernel so you do have a nice option to not fall too far behind. This has effectively replaced Bluefin GTS by bringing a relaxed desktop upgrade cadence and less regressions overall. The lts-hwe branches also now support secure boot. Despite these papercuts this is the image I use on my work machines, and the new architecture will help here.
Bluefin's Distroless Future#
Thanks to Sri Ramkrishna for contributing to this section
It is impossible to ignore the fantastic work happening in the the Linux Userspace API (UAPI) Group. Thanks to the work done by the bootcrew and Jordan Petridis it is now possible to decouple Bluefin from a traditional Linux distribution base image entirely and combine both UAPI and bootc approaches into one OS.
This new Bluefin is nicknamed Dakotaraptor and will be our attempt to ship a production quality bootc image based on GNOME OS. This gives us some benefits that we can't get from other images:
- Faster deployment of the best tech:
systemd-boot,systemd-homed, and other UAPI tech will ship much faster here - we can finally say goodbye to grub forever! - Testing branches with development versions of GNOME so that new contributors can help upstream development
- New GNOME and systemd teammates who are committed to driving and shaping the modern Linux desktop. This has been a boon for us since we're forging new working relationships with these upstream projects, and their help will keep us on the leading edge.
- More "take charge our destiny" by working with our critical upstreams directly instead of waiting for traditional distributions to catch up
Dakotaraptor will not be for everyone and will offer the least amount of compromises. Not only is local layering unsupported, there's no system package manager at all! We'll be using Buildstream since it's the tech behind this, and you'll hear more about it in 2026 as other projects check it out. This effort is still nascent, so no promises, but it's already got people excited, check it out at @projectbluefin/distroless.
JumpyVi's setup
Don't worry, we won't call it "Distroless".
The other Blufin OCI containers will still continue as before. Dakotaraptor will represent a faster development cycle, directly pulling from upstream, while maintaining production quality. Think of "distroless" as a model flip, the source is the main thing we interact with, the Linux desktop, and that's GNOME. And then we can bolt on whatever kernel we want, with modern Linuxes this is straightforward to make. And since the system libraries for GNOME OS are just ... the Freedesktop and GNOME runtimes, we're running on stuff that's already used by a ton of people. This way of assembly is new, but the payload is not.
That's why we're feeling confident about the quality out of the gate on this one. That just leaves a set of automation scripts and some config files, that's Bluefin!
We haven't yet finalized how next -> testing -> stable will look like, but having the next branch following the nightly GNOME development cadence is a goal. This channel will be our fastest raptor with aggressive component upgrades and no holds barred. The stable branch will be based on the stable GNOME builds and we're hoping to help GNOME maintain these branches. If you want to be part of this effort, now is the time to step up!
Oh, and in order to help us out with this you don't even need to talk to us, just go talk to GNOME directly. "Distroless" means spending more time with the things you love, and not so much time with the delivery service. We're mostly just waiting for GNOME 50 to come out. Expect this one to be VM-only for a while.
Refining the Bluefin Developer Experience#
About 60% of you turn on Bluefin's Developer Mode. We purposely focus on these 15.6 millions developers and strive to deliver the world's best cloud native development experience.
Now thanks to the efforts from the team homebrew is now in a much better state on Linux, allowing us to reshuffle some things around. In 2026 we will strive to remove the need for a dedicated bluefin-dx image and give you more flexibility moving forward:
- IDEs won't be baked into the images so you can use what you want.
- Homebrew will continue to be our path forward for IDEs - we hope to drum up interest so that the upstream projects can just "turn on" Linux builds in Homebrew. In the meantime we'll ship the major IDEs we need.
- We've added
containerdto the base images and will bring Docker in as well so that everything works out of the box, there will not be a need to do the adduser mumbo jumbo, we'll take care of that for you. Research in this area is still ongoing! - How we'll accomplish this transition is still a bunch of guesstimates, so consider this one a slow burn.
Curated Developer Experiences#
Thanks to to Vito Castellano from Bold Brew for continuing to improve the experience! Check out the Bold Brew v2.2.0 post to get more info! We've got all the issues fixed so this menu should work great moving forward. The intent is less stuff baked in, and more options, that you can freely install and remove. Note that these will also all work on any Linux with Homebrew:
The first is our ide selection, which offers a selection of VSCode, Codium, and Jetbrains toolbox for graphical IDEs, as well as nvim, helix, and micro for you CLI nerds.
The experimental-ide selection includes the individual Jetbrains products if you prefer to install those one-by-one, as well as Antigravity and Cursor. These will be promoted to the production tap as we get more feedback. We've also started to add Swift tools into the list so that we can tap into this exciting open source community!
Thanks to the new flatpak support in brewfiles we can ship all sorts of combinations now!
And finally, thanks to our custom tap we are investigating on how to bring bluefin-cli to MacOS, so that you can have these same convenience tools on multiple operating systems. James has a prototype that you can check out.
AI/Machine Learning Tools#
aka "Bluespeed"
Our AI toolset continues to expand. I'd like to highlight goose as a tool that I have been really digging into lately. Its donation to the Agentic AI Foundation makes this a great choice for your local LLM/CLI needs.
We've also added Codex, Copilot CLI, Gemini, LM Studio, Mistral Vibe, and Qwen Code to the list. Please continue to send us feedback on the tools you use.
Other Goodies#
And here's the stuff that doesn't fit anywhere else in this report!
- Consolidated ISOs - we'll be centralizing ISO building into one repository and plan on having regularly refreshed ISOs every month
- Powerwash is here! -
ujust powerwashis now in alpha and ready for testing - use this command if you want to blow away the data on your PC for donation. This wraps thebootc install reset --experimentalcommand for convenience behind some confirmation dialogs. Be careful with this one! Check the bootc documentation for more info - Actually Going to Market (GTM)
- We're almost to the point where we can start to market Bluefin instead of purposely going under the radar
- Investigating refreshed video content for the website - this will be expensive so we probably won't look into this until after the user-visible features have landed
- Updated Contributor Guide
Metrics#
On to the numbers! First off let's look at our critical upstreams. This level of growth confirms our decision to trust in systems that prioritize application developers.
- Flathub 2025 year in review - 20.3% Year over Year Growth, and Bazaar continues to get better all the time.
As you can see, we not only bet on Flathub, we worked with the folks at Bazaar to ship a pure Flathub experience on our images. If you're looking for one thing to donate to in 2026, please consider donating to Kolunmi - app development on Linux will never improve unless we invest in the application ecosystem directly.
- Homebrew Yearly Statistics - Bluefin (#11), Bazzite (#12), and Aurora (#15) have a strong showing in homebrew usage
This year we moved to LFX Insights as our platform. Here are our complete contributor metrics and a few charts. You can also always check out all our charts on our Analytics page, where we've finally crossed the 3k weekly users milestone!
I've selected some graphs, feel free to dive in and don't forget to check out Aurora and Bazzite too!
Development Roadmap(ish)#
Here's some important dates
- January 2026 - Bluefin LTS and Bluefin's transition to the common OCI containers is complete
- March 1, 2026 - Bluefin GTS moves to a F43 base and is merged into Bluefin
- April 2026 - Bluefin upgraded to F44 base (this includes all the former GTS users)
- Spring 2026 - Dakotaraptor alpha released
See you in 2026!#
This year the team plans to attend SCaLE again as well as the following conferences:
- KubeCon + CloudNativeCon Europe - see you in Amsterdam!
- KubeCon + CloudNativeCon North America - see you in Salt Lake City! The game is afoot, the key is:
lumina.
This ended up longer than anticipated, thank you for joining us in 2025, and we look forward to working with you in 2026! And lastly if you've made it this far and still want more backstory, make sure you check out this interview with Michael Tunnell:
Discussions#
Leave a comment or question!