I’m currently working on customizing Fedora Kinoite for use in an enterprise environment and would like to ask for your guidance and best practice recommendations.
Project Goals:
The objective is to create a customized Fedora Kinoite image with the following features:
Pre-installed tools (e.g., a specific VPN service)
Predefined configuration files
Optionally, prebuilt Toolbox or Distrobox environments
Automatic setup for laptops with NVIDIA graphics cards
A pre-configured, non-root user using Toolbox, Distrobox, and Flatpaks for daily tasks
Requirements:
The system should support automatic updates while retaining rpm-ostree benefits
Company-specific customizations should be maintainable and consistently applied across Kinoite updates
Ideally, an internal OSTree remote should serve the customized image
Automated provisioning (e.g., via Kickstart or other mechanisms)
Automatic disk encryption and filesystem setup (e.g., Btrfs)
Questions – Looking for Best Practices:
OSTree Infrastructure:
Is it feasible to build and manage a custom OSTree branch that acts as a middle layer between upstream Fedora Kinoite and the enterprise variant?
Automated Upstream Integration:
Are there established workflows to rebase or recompose company-specific changes into newer upstream Kinoite versions automatically?
rpm-ostree and Custom OSTree Checkout:
Can I create and manage a custom OSTree checkout using rpm-ostree, define custom refs, and deliver them via a private remote?
Use of bootc:
Would bootc be a better fit for this scenario compared to traditional rpm-ostree compose workflows?
Are there any advantages in using OCI/container-based OS images for enterprise rollouts, especially for automation, upgrades, and verification?
Recommended Tooling:
What tools or workflows are recommended for building, maintaining, and provisioning such systems (e.g., rpm-ostree compose, bootc, ignition, butane, kickstart)?
I’ve found several related resources (rpm-ostree docs, Silverblue guides, Universal Blue, etc.), but due to the variety of approaches, I’m unsure which path is the most stable and maintainable for production use.
Actually yes.
There are many experimental approaches out here, so i do not really know how to start.
The main question i have is:
Is it possible to use OSTree and RPM-OSTree combined, without destroying the tree and render the basic function of kinoite useless.
Some feature are quite new and i just want to get some information, some guidance which approach is the most reasonable.
The “branded” system should bring some packages and files with it, nothing extreme special.
Basically → get the new Kinoite image → add these files and packages → wrap it into a new image.
Using a own OSTree or Repo to have the possibility to sync new versions of specific packages would be great.
And yeah i know, the message reads like AI slop, cause it is.
Was not the best Idea to “summaries” my question with it. Sorry for that.
Bootc is the way. I believe Red Hat is beginning to steer its customers in this direction, so it’s going to be supported for the long haul. The Atomic Desktops are going to be moving to bootc over the next few releases from what I can see.
It’s a lot simpler to deal with – you don’t have to mess with serving up an OSTree repo, just use a container registry you probably already have. (Or use Github’s container registry if you don’t mind your images being public.) Keeping up with your upstream is pretty easy – just rebuild your container when your base container changes, push to the registry, and your machines will pick it up automatically.
You will probably want to check out Universal Blue. They have a base Kinoite image with “batteries included” (Package kinoite-main · GitHub) you can start from, and a branded image that’s a bit more opinionated called Aurora. I’ve been daily driving a customized Bluefin (think Aurora, but with GNOME) on multiple machines for more than a year now, and I’m pretty happy with it.
Some of your questions don’t make sense (and were likely AI generated), but in general, you should be able to use the Bootable Container images either from Fedora or Universal Blue and tweak things to get something that matches the requirements of your environment.