Image Builder for Fedora

What is Image Builder

Image Builder is a service that is part of the RHEL product pipeline and is on its way to becoming a part of the Fedora image build pipeline. In addition to building standard composes by integrating with Koji, it offers end-users a way of building customized operating system images for various architectures (x86, ARM, IBM) and targets (Bare metal, Private cloud, Public clouds). The way it exposes configurations and customizations is geared towards producing images that boot and are useful. Image Builder is available through for anyone with a RHEL subscription.

While the service is currently a Red Hat offering, the team has been working to make it open source where it can. You can read our self-assessment here.

Here are some useful links:

What’s the plan

We want to deploy Image Builder (see below for details) as the first service of what we hope will eventually become Image Builder is a great candidate, because it’s fairly standalone (doesn’t depend on a lot of Red Hat Insights or other Red Hat specific components/services) and provides value without any controversial features that Insights comes with (e.g. the usage of insights-clients, the concept of subscribing, telemetry, etc)

Phase 1: Proof of concept

We would like to build and deploy a proof of concept on

In the first iteration, there’d only be a public API with basic authentication. It would look like this: API Catalog and allow select ‘preview’ users to build customized Fedora images via this API.

Phase 2: An authenticated backend

In the second phase, we would try to tackle the authentication, specifically integrating with the Fedora Account System via OIDC.

Phase 3: A service with a frontend

In the third phase we would deploy the frontend for the service, so logged-in users could use it to see their previous builds etc.

Who is providing what

The Image Builder team will provide:

  • An Image Builder service and a Content Sources service (so end users can build images with custom content from e.g. COPR)
  • All operational support (best-effort dev team support during EMEA office hours, basic best-effort AppSRE support for the rest)
  • The service would be hosted on Red Hat clusters
  • Deployments, updates, etc would go through Red Hat infrastructure

Fedora will provide:

  • DNS
  • OIDC

How would users get support

We currently have three avenues:

  1. GitHub issues upstream or issues in Red Hat’s Jira
  2. A matrix channel on
  3. A public mailing list

I am the Technical Marketing Manager for RHEL’s image builder. If I can be of ANY help on this, please let me know.


I think this is really cool. It provides a useful service for the Fedora community, and helps Red Hat service offerings like this act as active open source.


I am looking forward to use Image Builder for Fedora use cases. And Open Service is the most exciting concept for me.

I am a bit worried about the naming here and whether it sets the expectations right.

I would expect that services run under * name are not just being deployed for Fedora or using Fedora, but they are also governed by Fedora. So how is it supposed to work here? Who is going to own the decision making on what merge and not merge in the service configuration?

Is it really a or more like or


Hi Aleksandra,

Thank you for the positive feedback! :slight_smile:

In terms of naming we’re open to your suggestions and we definitely want to set the right expectations. You certainly have a better view of what the community might think/expect.
When proposing, my intention was to aim for the stars and inspire others currently running services on to follow our lead.

On the topic of governance, I wanted to add that I see two ways for Fedora to influence and take ownership of the service:

  1. The artifacts (i.e. images built) are based on image definitions which we would like to be owned by Fedora. E.g. when we build the official Fedora spins, we would expect that the owners of the spins would own what goes into those images.
  2. The deployment logic currently goes through app-interface, but the deployment metadata/config is open (minus the secrets obviously, see e.g. and the file describing the Fedora service could easily be put under Fedora governance.
1 Like

I guess this is a key question: who can earn commit access to the project?

Hi Matthew,

This is a bigger topic that we’re thinking about a lot. There’s a lot of ideas floating around about how to make these image definitions easier to work with for external contributors and maintainers. Currently, it’s all included in the repository that Simon linked to and it’s pretty much all Go code. We understand that, while this has certain benefits, it isn’t ideal for the situation we’re discussing here and we’d like to work with you to find the best way forward.

It can be (maybe at first) a simple matter of bringing people into the project in its current state, making them code (co-)owners of the pkg/distro/fedora/ package. We also have ideas about restructuring the images to have less defined in code and support more in the external configuration, essentially enabling spin definitions to exist as build configurations.

Ultimately, the answer to your question will depend on where we (IB and the Fedora community) land on the above.


@mattdm I think it might be not that.

(I haven’t really formed my opinion so I am thinking out loud here)

Maybe consider the examples: - this is the most classical Fedora service. There is Koji as upstream project, where Koji developers make decisions what to merge and not to merge. And then there is CPE-owned deployment procedure to rollout changes and configure the Fedora instance of Koji.

But there is another service, like - it is provided to Fedora by a third-party according to a certain agreement. Within that agreement Fedora Project owns the internal configuration, but doesn’t have the merge power for the code. The governance is channeled through you, and the Fedora Council.

As far as I understand currently image-builder service would be less open and accessible than Koji but much more open than Discourse or Matrix.

And from that example it look like should be ok.

I think in the end I am less interested in who has the actual practical permission to merge the code in the repo (if we have a merge request workflow where reviews happen collectively and in the open I am not too worried about it). Rather I think the question is - should we have some agreement about more high-level decision making, like enabling/disabling an arch, or managing access to the service or I don’t know, things like limiting the amount of builds per user…

Can we get CPE (or, more generally, Fedora Infra team) to be the “owners” of the service the same way how they own Matrix or Discourse now. And then watching after what is going on there and bringing things to attention of Fedora Council or FESCo if needed? Or should we setup a separate group for this?


I think this is a very interesting idea, and well worth persuing…

I think it’s probibly fine for fedora infrastructure to help route requests to the right place, represent the users/consumers of the service and ask for fixes/changes if needed.
I think it’s pretty similar to the matrix/discourse setups… although in this case it may be less possible for us to ‘self manage’ some parts of the application (although I am not sure of that? can we have the ability to change arches/limits/etc on the fly without involving any of the console team?).

One other thing that might be nice is some kind of reporting? ie, can we look and see how many images were made, what kind or something? That might help adjusting the service and seeing that it’s useful for community members.

Some great questions from @bookwar :slight_smile:

Will the Image builder bring get a trivial (or at least easy) way to build custom bootable Fedora installation ISOs?

1 Like

Will this be accessible just to Fedora Infra/Spin owners, or to specialized groups as well? I’m in Quality and we often have a use case where we need to build an installer image with a certain package from updates-testing or Koji included (and then ask a community member to test it, for example). Currently we need to build it ourselves and then host it somewhere. It would be outstanding if we could log in to Image Builder, perform an installer image build with a particular set of package NVR overrides, and then receive a public URL to download it. Will that be possible?

I don’t know if this is possible now, but I think this should be a very high priority feature for entire range of use cases: Fedora CI, CentOS CI and RHEL CI also need that.

My dream is that for every MR/PR we would get an image built with the updated package and use it in local testing, Testing Farm, OpenQA and/or Zuul pipelines. It would simplify a lot of our pipelines and test scenarios which won’t need to handle fetching and updating packages during the test run.

For things we actually rely on for the distribution to function, I would prefer us to be closer to Koji than Discourse in terms of services. Especially given the architecture of OSBuild and Composer, not having that ability means we can get in a lot of trouble with IB bugs during release development.

1 Like

I certainly don’t want to get into the situation we ended up in for Module Build Service, where it was essential to our compose pipeline but no one believed they actually owned it or were responsible for making it work. We’d need some kind of strong agreement of expectations before using it in a release-blocking way.

For things we actually rely on for the distribution to function, I would prefer us to be closer to Koji than Discourse in terms of services.

I chose Discourse as an example for the very end of the spectrum, not as a role model :slight_smile:

I agree that with Image Builder we should get much closer to the Koji setup.

When I say I don’t pay a lot of attention to who exactly merges things - that’s because I think that in code review workflows real decision is made before you hit a button to merge. The actual person who hits a merge button implements the decision made through the code review process.

As long as the code review process is open, and the owner of the merge button respects it, they may have it.

Like when you ship a change in Fedora you may not have access to a signing key, yet it is you who decide what to ship. The signing key owned by a certain infra engineer is the implementation detail here. And the power over that key is used to verify not to change the outcome.

I think that I am moving in the direction that we should deploy the staging instance and see how this works in practice, including the expectations from the infra accessibility (access to monitoring, debugging, logging) so that we can then make more explicit requests on what we should and should not do.

I think there may be some confusion here. (Or perhaps I am confused! :slight_smile:

This thread is taking about providing imagebuilder for the fedora
community. ie, users, developers, whoever wants to make a custom image
for whatever reasons. Of course there will be limits, X images per Y
time to avoid resource problems/abuse, but otherwise (once it’s deployed
in production) it will be available to anyone with a fedora account.
(please correct me if I am mistaken!)

I think there might be some confusion here. This is talking about
providing a service to the fedora community.

There’s a related effort to move composing official images into osbuild.
That effort wouldn’t be using this instance I don’t think.

So, this is just for users/community folks to build images.

note, you can always have the robot do this for you. openQA already builds live and installer images for many updates. if it’s not in the critical path groups that would make it do that, we can easily manually schedule those tests on staging to get images built. I can show you how to do that if you like.

Yes, but also Fedora for other targets like public clouds.

1 Like

Indeed, there’s a related effort where we’re working with Fesco to make image builder part of the Fedora pipeline.
This proposal is purely for a community offering, where anyone with a Fedora account would be able to log in and build customized images.