🚀 [Proposal] Integrating Fedora bootc Base Images into the Official Fedora Releases

Project Discussion
1

I’m opening this thread to gather thoughts and community feedback around a proposal to officially include Fedora bootc base container images in the Fedora ecosystem, with the intention that people will consider submitting this as an official Fedora 43 Change proposal.

This comes as part of a broader initiative to support bootable containers (bootc), an exciting new approach to deliver OS environments as OCI-compliant container images that can be booted directly on bare metal or virtual machines. These bootc images align well with Fedora’s innovation goals and could serve a new generation of edge, cloud, and embedded systems use cases.

:pushpin: Background

The request originated who have been actively building Fedora-based bootc images and testing them through automated pipelines. Now that the builds are stable, there’s interest in:

  • Publishing these images publicly
  • Integrating them formally as part of the Fedora release artifacts
  • Allowing the community to use, test, and iterate on them

Traditionally, Fedora adds new image types at release boundaries through the Change process, so the ideal path forward would be to submit this as a Fedora 43 Change and begin shipping these images as part of the release.

:compass: Proposal Summary

:white_check_mark: Goals:

  • Ship fedora-bootc base images alongside other Fedora deliverables
  • Host them in Fedora’s official container registries (like quay.io/fedora)
  • Ensure they meet Fedora’s security, naming, and metadata standards
  • Align this initiative with Fedora’s infrastructure, signing, and release processes

:pushpin: Key Considerations

1. Where will these images live?

Current options:

  • Short-term (testing): quay.io/fedoraci or quay.io/fedora-testing/fedora-bootc
  • Long-term (release): quay.io/fedora/fedora-bootc

We recommend final delivery to quay.io/fedora/fedora-bootc for production use, and possibly phasing out registry.fedoraproject.org in the long term.

2. Do these images require formal review?

We’d like to discuss:

  • Should this go through the Fedora Container Image Review process?
  • Is a Change proposal enough to handle inclusion?
  • What group (Cloud SIG? QA? Infra?) should help us vet and sponsor this?

:magnifying_glass_tilted_left: Who can help sponsor and shepherd the image through the inclusion process?

3. Tagging & Metadata

To comply with Fedora standards, the image should:

  • Follow naming conventions: fedora-bootc (not version or branch specific)
  • Include proper OCI metadata (e.g., labels like name, summary, version, etc.)
  • Use date-based tags or semver, along with :latest

4. Security & Signing

Fedora requires image signing, so we’ll need:

  • Koji (or alternative) signing integration
  • Regular scanning (e.g., Trivy, Clair)
  • Possibly including SBOMs

:magnifying_glass_tilted_left: What’s the best way to handle signing and vulnerability scanning if we host these images on Quay?

5. Integration into Fedora Infra

The current build system is an external pipeline, but we want to ensure:

  • Fedora Infra can consume logs and build metadata transparently
  • Long-term compatibility with Fedora CI/CD expectations

:paperclip: Related Work & Konflux Integration

This effort is already being discussed in multiple places:

A Fedora Konflux cluster is now operational, and contributors have already offered support to help transition bootc image builds into this shared pipeline. This could become an important component of the proposed Fedora 43 integration work.

:hammer_and_wrench: Suggested Path Forward

Here’s how we could proceed toward Fedora 43:

  1. Submit a Change Proposal: Clearly defining deliverables, registry target, image definition, and compliance scope.
  2. Prototype & Test in Parallel: Continue testing via quay.io/fedoraci to gather feedback.
  3. Image Review & Metadata Compliance: Collaborate with interested SIGs or QA teams to ensure the base image meets Fedora standards.
  4. Establish Signing Pipeline: Work with Fedora Infra or Release Engineering to secure and verify images.
  5. Monitor & Iterate: Include feedback cycles post-beta or RC testing to adapt prior to final release.

:man_raising_hand: Open for Feedback

I’d love to hear from:

  • SIGs or groups who’d like to co-own or sponsor this effort
  • Infra folks on registry/signing integration
  • Community members on use cases or blockers you foresee
  • Release engineers and QA about how this fits into our testing matrix

You can also join the discussion or leave comments on the RelEng ticket #12731, which I’ve opened to coordinate progress and gather input from other stakeholders.

Looking forward to your thoughts!

—
Samyak

3 Likes
2

Sorry for the long delay here, keep not getting to replying here, but finally I have!

  1. That sounds fine to me. quay.io is our plan… note that we do have a ‘fedora-testing’ org that can be used for initial setup and test before rolling to the main repo.
  2. The container image review process is… not used anymore since we don’t make any container images (except for the base / minimal ones). I would like to see some kind of formal review process tho, not sure if it should be similar to the container image one or more taylored to these. I think a change is a great step and hopefully will show what things are missed. :wink: As for who, not sure, I would think the community in general.
  3. Sounds good. Also, we should be clear what (if any) of this is release blocking. I would assume non of it to start with…
  4. Not sure on signing, it will need to be investigated.
  5. yeah.

I think the biggest ask here is to use konflux to produce ‘official’ images. A note/background in the change about how reliable and open and ready that it would be good to have.

Thanks for bringing this up!

3

Note we are already building and delivering a bootc base image using the ‘old-fashioned’ pipeline, as part of the IoT compose, e.g. https://kojipkgs.fedoraproject.org/compose/iot/Fedora-IoT-43-20250530.0/compose/IoT/x86_64/images/Fedora-base-bootc-x86_64-43.20250530.0.ociarchive . It’s published on quay as fedora-bootc - Quay .

It should be relatively easy to move it from the IoT compose into the main compose, I think.