Jorge O. Castro

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!

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.

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 containerd to 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 powerwash is 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 the bootc install reset --experimental command 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!

We hope that you're enjoying the holidays! We're making some important changes to how Homebrew and command-line tools work in Bluefin. These changes will land in this Tuesday's weekly build.

Homebrew​

Homebrew's path will now be placed after the system path. This will cause brew doctor to complain, but we feel that this will lead to a cleaner experience overall. This has been working well in testing, and the change is already on the daily builds if you're using one of them.

Bluefin CLI​

Atuin has been causing some issues, so we've disabled it by default to ensure a stable experience with bluefin-cli. We plan to investigate a better integration for Atuin in the future.

More updates coming​

We will be publishing a large year-in-review update next week that will cover these topics in much more detail, but we wanted to give you a heads-up on these behavioral changes before they land. In the meantime, we've set up todo.projectbluefin.io for you to follow along with the major changes coming in Bluefin. Thanks!

Discussion​

We've created a new repository to make it much easier to add Homebrew to your custom bootc images. @ublue-os/brew repository provides a pre-packaged OCI container image that bundles everything you need to add Homebrew to your custom image-based systems. This is an evolution of a long journey to integrate homebrew better onto our Linux systems. Instead of manually setting up Homebrew, configuring services, and managing shell integrations, you can now include everything with a single line in your Containerfile.

COPY --from=ghcr.io/ublue-os/brew:latest /system_files /

On first boot, the brew-setup.service automatically extracts Homebrew to /var/home/linuxbrew/.linuxbrew, sets up proper permissions, and makes it ready to use. The image also includes timers for automatic updates and upgrades, keeping your Homebrew installation current.

This removes a bunch of the manual stuff you had to do in your template to get the full thing, now it's much easier and reliable for everyone. Once we're done the container will rebuild after a Homebrew release, keeping us up to date and safe!

Check out the repository at github.com/ublue-os/brew for more information and examples.

Thanks!​

This work and testing brought to you by:

Discussions​

Working with artists can be fun because they all move at different schedules so sometimes when it rains it pours.

We're excited to announce two beautiful new wallpapers: Andy Frazer's latest creation Huntress, and a festive holiday wallpaper from Aurora.

Huntress by Andy Frazer (Dragons of Wales)​

Original Bluefin artist Andy Frazer returns with Huntress, a stunning new addition to our wallpaper collection. Following his previous work on Dusk, Andy continues to bring his distinctive paleoart style to Bluefin. We were going for a more weathered Bluefin this time around. No longer the ideal one perched on a rock ... this one has been through some things.

Andy's books make excellent gifts for dinosaur enthusiasts of all ages. Check out his Etsy shop for his full collection of paleoart books and prints.

Holiday Blues by Chandeleer​

This next one is by Chandeleer and captures all of the mascots from Aurora, Bazzite, and Bluefin playing in the snow.

If you enjoy Chandeleer's work, please consider supporting them through their Ko-fi page.

How to Install​

These wallpapers are available through the @ublue-os/homebrew tap. We've finally solved the teething problems with the tap and we now consider it production ready. You can install them using ujust bbrew and selecting the artwork option: (this is broken right now sorry). We do not yet ship these by default so right now they are opt in:

Installing Bluefin Wallpapers Extra​

To get the Huntress wallpaper and other extra Bluefin wallpapers:

brew install ublue-os/tap/bluefin-wallpapers-extra

And for the Aurora artwork:

brew install ublue-os/tap/aurora-wallpapers

Download Directly​

You can also grab these wallpapers directly from the artwork repository:

• Huntress
• Holiday Blues

Happy holidays from the Bluefin team!

Discussion​

We've added two pages of documentation today:

Driver Versions Page​

Regressions suck. And it also sucks finding out where they happened, especially with the power of bootc switch available! What good is a switch if you don't know where to switch to! I hate looking this up by hand, so we whipped this up:

The Driver Versions page tracks kernel, NVIDIA driver, and Mesa versions across all Bluefin release channels. This consolidated view makes it straightforward to:

• Troubleshoot driver-specific issues - If a recent update broke something, you can identify exactly which driver version changed
• Switch to specific versions - Each release links directly to the GitHub release notes and includes bootc switch commands
• Compare channels - See how stable, GTS, and LTS differ in driver versions at a glance

The page includes direct links to upstream release notes for NVIDIA drivers and Mesa, so you can dig into the details when needed.

Improved Extensions Section​

The Tips and Tricks page has a new refreshed look with extension thumbnails. We haven't touched these in a while, but the reason I was there was to add Copyous to our list of recommended extensions. This thing is so good! It puts a strip of clipboard items on the top that you can summon:

Kick the tyres and let us know what you think!

Discussions​

I had the pleasure of sitting down with Michael Tunnell to discuss Aurora, Bazzite, Bluefin, cloud-native Linux desktops, and the future of the project.

Check out TuxDigital and This Week in Linux.

Discussions​

Flatpak support in Brewfiles is here! You can now manage your Flatpak applications alongside your Homebrew formulae, casks, and other dependencies in a single Brewfile. This is thanks to the amazing work by Ahmed Adan (Donate), who worked with upstream to land this feature.

What's New​

Homebrew Bundle now supports Flatpak packages on Linux. This means you can declare your Flatpak applications in your Brewfile and have them installed automatically with brew bundle.

Note from Jorge: I haven't played with this feature yet but announcing it so we can get feedback right away.

Basic Usage​

Add Flatpak packages to your Brewfile using the flatpak directive:

# Brewfile
brew "neovim"
flatpak "com.spotify.Client"
flatpak "com.visualstudio.code"

Then run:

brew bundle

Remote Support​

Homebrew Bundle supports three ways to interact with Flatpak remotes:

Default Remote (Flathub)​

For packages from Flathub (the default), just specify the app ID. Most of us will use it this way:

flatpak "com.spotify.Client"

URL Remote​

For packages from other repositories, specify the remote URL:

flatpak "org.godotengine.Godot", remote: "https://dl.flathub.org/beta-repo/"

Named Remote with URL​

For shared remotes that you want to reuse across multiple packages:

flatpak "org.godotengine.Godot", remote: "flathub-beta", url: "https://dl.flathub.org/beta-repo/"
flatpak "io.github.dvlv.boxbuddyrs", remote: "flathub-beta"

Commands​

All the standard brew bundle commands work with Flatpak:

• brew bundle - Install Flatpak packages from your Brewfile
• brew bundle dump - Export your installed Flatpak packages to a Brewfile
• brew bundle cleanup - Remove Flatpak packages not in your Brewfile
• brew bundle check - Verify all Flatpak packages are installed
• brew bundle list --flatpak - List Flatpak packages in your Brewfile

Check out the brew bundle documentation for more information.

Dump Options​

# Include Flatpak packages when dumping (default on Linux)
brew bundle dump

# Exclude Flatpak packages
brew bundle dump --no-flatpak

# List only Flatpak packages
brew bundle list --flatpak

Why This Matters for Bluefin​

This feature allows Bluefin users to maintain a single Brewfile that manages:

• Command-line and GUI applications in one file
• Lightweight gitops between all of your machines
• Paves the wave for better Homebrew/Flatpak integration

The huge community benefit is the shareability of a list-o-files. You can give your friend the hookup, and in fact many of Bluefin's "features" are just us shipping our own Brewfiles. For you experts out there this likely just simplifies something you probably already have. And for those of you just starting your command line spec tree it's a nice milestone to hit: "I can get a new install up and running in 10 minutes". There's lots of ways to do this, but this is an easy one. 😄

Woo! We feel that this is a nice complement to devcontainers, providing even more flexibility to your workflows!

How does it work in practice?​

You're going to have to tell me, I am on holiday in the German countryside, but this feature is super exciting and I'm looking forward to hearing your feedback!

Refer to the Homebrew Bundle documentation for more!

References​

• Pull Request: Add Flatpak support to brew bundle
• Issue: Feature Request - Add Flatpak support to Brewfile

Also Check Out​

Speaking about "Easiest way to get a clean install in 10 minutes", SaveDesktop is the nice GUI way to do this. You'll always find it in Bluefin's Curated section in the Bazaar app store. (Tell your friends!)

Discussion​

Happy Thanksgiving for those of you in the US eating dinosaurs! Today I am happy to show off some of the recent collaboration we've been doing with some awesome paleoartists. We've covered this before but now the collection is complete!

Natalia Jagielska​

Our newest collaboration is with Dr. Natalia Jagielska, a world renowned expert paleontologist and paleoartist! I've always been a huge fan of her art style and she has graciously given us three wonderful pieces of art. The first you probably already recognize since it's been the wallpaper of the month for November, entitled Collapse:

The second is an homage to Ubuntu's famous Hardy Heron wallpaper, originally designed by Ken Wimer. This one is a mashup of one Natalia's pterosaurs in place of the heron. This one is called Tenacious Pterosaur.

And lastly we have Prey, starring a hungry Venetoraptor gassenae, which is a pterosaur ancestor from the Triassic. This one surprised me, I thought it was a mammal at first!

Natalia's artwork was vectorized and remastered by Delphic Melody, please consider donating so that the collaboration can continue!

Andy Frazer (Dragons of Wales)​

Original Bluefin artist Andy Frazer returns with Dusk. I love this one.

Also Andy is working on another Bluefin for us, which I haven't seen yet. I can't wait to find out! Andy also has a 25% off special on all his books. I have a few of these and they are not only awesome to own but make great gifts as well.

How to get them​

This is not yet included by default so you can hop in early with a ujust bbrew and select artwork. In the future this will be automated for you:

bluefin-wallpapers-extra will bring this collection in. Also you will notice that the Aurora and Bazzite artwork collections are available. This tap is distro agnostic so go nuts putting dinosaurs, cone people, and mechs everywhere!

You can also just grab them from the repository if you prefer to do it that way. Stay tuned for a special holiday wallpaper, coming soon!

Discussion​

Greetings guardians!

A few minor updates today, you'll receive these updates either today or tomorrow depending on the build you're on. Our first is some updates to our usage of just. Just is a task runner that we use to ship community aliases. Our justfiles are ancient, some going back to the beginning of the project. We are consolidating most parts of what you call "Bluefin" into a common repository. These are all mostly scripts, there's nothing distribution specific about them.

We wanted to centralize this because keeping Bluefin and Bluefin LTS configs in sync is too problematic. In this manner we can make the Bluefin parts easily plop onto any image no matter what the image is.

It also means we cleaned out some broken stuff, and are down to just 34 just recipes, which makes all of this sustainable, especially since we're sharing the maintenance with Aurora. All the recipes now include confirmation dialogs and have been refined. I am glad we got this done because this part of Bluefin was really starting to show its age! Thanks to @tullilirockz for working on this! Thanks to @hanthor for implementing it in Bluefin LTS! Run ujust or ujust --choose to get started!

Bold Brew and Brewfiles​

We now have a nice way for the community to contribute to Bluefin's Brewfiles.

We workshopped some ideas on how to make this nicer for users. We approached bold-brew with the idea of presenting Brewfiles to users in a dedicated view. Vito was very accomodating and implemented the idea, kudos to him! Now let me show you how it works:

ujust bbrew is the entry point, we will generate a little menu for you for every Brewfile in Bluefin. So if we add more they just show up here. Then after you choose one bbrew will open up showing you that Brewfile. You can then select and choose what you want to install, or hit Ctrl-A to grab everything.

Bold Brew is to Homebrew what Bazaar is to Flathub​

This is awesome because we can now curate app bundles of CLI tools to users. We're starting off with AI tools, k8s tools, and monospace fonts. Feel free to send PRs to these Brewfiles, since users can pick and choose we can ship the tools you depend on the most. You'll also notice some color improvements in bbrew, make sure you check out the repo and give them a star!

More Cloud Mumbo Jumbo​

And lastly, we now have ujust cncf, which will show you all of the projects that are part of the CNCF. Many of you work with these tools every day, the hope is to show you all of the cool things you can play with in cloud native!

More Consistent Bluefin​

Ultimately this consolidation of all of our config will lead to better Bluefins and has been a primary source of parity issues between Bluefin and Bluefin LTS. Bluefin continutes to actively shrink over time!

We still have work to do, like the motd, bling, and all that other stuff but we'll keep you up to date!

Discussion​

We're doing this for a few reasons:

• The value GTS provided is "older software works better". What it really means is "no one messed with this", changes still made in Bluefin affect this branch immediately.
• bluefin:latest - this one is an antipattern, you want to be able to pin something, and people make assumptions of what it means. We'll transparently move you to bluefin:stable-daily.

If you're new here there's no need to panic, bluefin:gts and bluefin:stable always share the same version twice a year for a few weeks. We're in that period now, they're both at Fedora 42.

In the meantime let's pretend it's out so that we can continue to Bluefin's new model. The workflow looks like this currently:

Current Bluefin (November 2025)​

This has resulted in confusion, especially as Bluefin LTS has come up to speed. So starting in the Spring of 2026 we're moving to this layout:

Future Bluefin (Spring 2026)​

Changes and Rationale​

At first this looks like a rename, so let's go over the changes:

• bluefin:next - all changes will land here first. We make no stability guarantees. It will build daily. This will not replace bluefin:latest because we will for sure break things in here. This will build at least daily and every time a change lands
• bluefin:testing - When changes in :next have been tested by at least one person they queue up to land in testing. We anticipate things to sit in here for a week or two at a minimum unless we need to fix a regression. This builds daily.
• bluefin:stable - This is effectively the current version of Fedora, except all changes going into this will have at least be vetted by the previous branches.

We do NOT have this promotion process today. This is the goal. If you are on bluefin:latest we will point you to bluefin:stable-daily so that you are still getting daily builds. We purposely are not moving you to next because that will be volatile. Both the next and testing branches will be opt in.

Benefits​

For You​

• Less confusion, you either download Bluefin or Bluefin LTS.
• Better testing in general as we add tests to each step before promotion
• TLDR: Everyone moves to bluefin:stable in the Spring, and those of you who want newer stuff can opt into testing and next

For Us​

• Testing workflow allows for super fast iteration and two stages of testing before hitting end users. This is the #1 reason to do all of this
• We no longer have to keep GTS bits around the rest of the org to support it, freeing up builder space and resources
• Better alignmed with Fedora CoreOS development

This does mean that we will no longer be shipping the stock Fedora kernel in any branch. We're fine with this since we prefer to keep all our users on a gated kernel.

Discussions and Questions​