BOOTC-RELATIONSHIPS(7)

💖 BOOTC-RELATIONSHIPS(7) 💖

okay bestie, so this is a page from the Miscellaneous Information Manual and it's all about how bootc ~relates~ to other projects. grab a boba, we're doing lore. 🧋✨

---

✨ NAME ✨

bootc-relationships — the whole "who are we to each other" situation with other projects 💕

---

💅 DESCRIPTION 💅

So bootc is the main character in a bigger mission: bootable containers (the whole thing lives at https://containers.github.io/bootable/). And here's how it vibes with all the other moving parts. 🦋

🌸 Relationship with podman 🌸

okay so talking about shipping bootable operating systems inside container images gets confusing, lowkey. Let's be crystal clear: we're reusing container images as

• a build mechanism (which includes running as a standard OCI container image) 🏗️
• a transport mechanism 🚚

BUT. Here's the tea ☕: when a bootc container actually gets booted, podman (or docker, etc.) is not involved at all. The storage used for the operating system content is separate from /var/lib/containers. So podman image prune --all will not delete your operating system. like, it literally can't touch it. 💀🚫

That being said, a toplevel goal of bootc is alignment with the https://github.com/containers ecosystem, which does include podman. But on a more technical level, specific to today: bootc uses skopeo (https://github.com/containers/skopeo/) and therefore indirectly containers/image (https://github.com/containers/image) as its way to fetch container images. 👑

Which means bootc automatically honors a ton of the knobs available in /etc/containers — specifically stuff like containers-registries.conf (https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md). 🎀

In other words: if you configure podman to pull images from your local mirror registry, bootc will automatically honor that too. no extra work, it just gets it. 🫶

The simple way to say it: a goal of bootc is to be the bootable-container analogue for podman, which runs application containers. Everywhere you might run podman, you could also consider using bootc. periodt. 💅

🏗️ Relationship with Image Builder (osbuild) 🏗️

There's a new bootc-image-builder project (https://github.com/osbuild/bootc-image-builder) that is entirely dedicated to the intersection of these two!! it's giving collab. it's giving crossover episode. 🔥

☸️ Relationship with Kubernetes ☸️

Just like podman doesn't depend on a Kubernetes API server, bootc will not depend on one either. independent icon behavior. ✨

However! There are also plans for bootc to also understand Kubernetes API types. See the configmap/secret support (https://github.com/bootc-dev/bootc/issues/22) for example. 👀

And maybe, in the future, we might actually support some kind of Pod analogue for representing the host state. Or we may define a CRD (https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) which can be used inside and outside of Kubernetes. versatile queen. 🌈

🌳 Relationship with ostree 🌳

OSTree provides so many things, bestie, a whole bundle:

1. a git-like repo for OS data from which you can check out an entire rootfs 📦
2. a bootloader integration layer 🥾
3. a transport layer for pulling content over HTTP 🌐

With bootc, the OSTree transport layer is not used. Instead, content is pulled as OCI containers using skopeo, as mentioned above. However, this content is then imported into the local OSTree repo to perform a deployment checkout. The role of OSTree may further shrink in the future, especially as tighter integration with podman and composefs occurs — but it will remain an important part of the bootc stack (in particular the bootloader integration layer and management of deployment roots). so like, glow-down later maybe, but never fully leaving the group chat. 💜

🔄 Relationship with rpm-ostree 🔄

As mentioned above, bootc uses OSTree as a backing model, and so does rpm-ostree. Hence, when using a container source, rpm-ostree upgrade and bootc upgrade are effectively equivalent — you can use either command. pick your fave, no wrong answer. 🎀

💀 Differences from rpm-ostree 💀

• The ostree project never tried to have an opinionated "install" mechanism, but bootc does with bootc install to-filesystem. it has OPINIONS. ✋
• bootc has additional features such as /usr/lib/bootc/kargs.d and logically bound images (see bootc-logically-bound-images(7)). extra content, we ate. 🍽️

🧚 Client side changes 🧚

Currently, all functionality for client-side changes such as rpm-ostree install or rpm-ostree initramfs --enable continues to work, because of the shared base. 🫶

However — and this is the important part, bestie — as soon as you mutate the system in this way, bootc upgrade will error out, because it will not understand how to upgrade the system. The bootc project currently takes a relatively hard stance that system state should come from a container image. so like. don't be doing that. 😭

The way kernel arguments work also uses ostree on the backend in both cases, so using e.g. rpm-ostree kargs will also work on a system updating via bootc. so that one's chill. 😌

Overall, rpm-ostree is used in several important projects and will continue to be maintained for many years to come. respect the elders. 👑

However, for use cases which want a "pure" image based model, using bootc will be more appealing. bootc also does not, e.g., drag in dependencies on libdnf and the RPM stack. lightweight queen behavior, honestly. 🪶

bootc also has the benefit of starting as a pure Rust project; and while it doesn't have an IPC mechanism today (https://github.com/bootc-dev/bootc/issues/4), the surface of such an API will be significantly smaller. small API = clean API, we love that for us. ✨

Further, bootc does aim to include some of the functionality of zincati (https://github.com/bootc-dev/bootc/issues/5). 🎯

But all this said: it will be supported to use both bootc and rpm-ostree together — they are not exclusive. For example, bootc status at least will still function even if packages are layered. besties can coexist!! 🫶💖

🔮 Future bootc <-> podman binding 🔮

All the above said, it is likely that at some point bootc will switch to hard binding with podman (https://github.com/bootc-dev/bootc/pull/215).

⚠️ Heads up, this has consequences: it will reduce the role of ostree, and hence break compatibility with rpm-ostree. When such work lands, we will still support at least a "one way" transition from an ostree backend. But once this happens, there are no plans to teach rpm-ostree to use podman too. so like, it's a one-way door, not a revolving one. 😬

🐧 Relationship with Fedora CoreOS (and Silverblue, etc.) 🐧

Per above, it is a toplevel goal to support a seamless, transactional update from existing OSTree based systems, which includes these Fedora derivatives. slick transition, no drama. 💅

For Fedora CoreOS specifically, see this tracker issue (https://github.com/coreos/fedora-coreos-tracker/issues/1446). 👀

See also OstreeNativeContainerStable (https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable). 📚

---

👀 SEE ALSO 👀

bootc(8), bootc-docs(7), bootc-logically-bound-images(7)

go read those too, bestie, i'm not kidding, they're relevant 🫶✨

---

⭐ VERSION ⭐

v1.17.1

---

okay that's the whole page, you're officially caught up on the bootc extended universe 🌸 tysm for reading, this was the Miscellaneous Information Manual's BOOTC-RELATIONSHIPS(7) page, version v1.17.1, and yes i am obsessed with it. mwah, slay, go boot something. 💖👑🦋