I do 
As a solutions & app architect / developer; I only dabble in devsecops (I’m retired now).
@zee-eff-ess Homework assignment for you. Create a distrobox, enter it and do a $ mount command. The output of that for me is 348 lines right now. Most of those are there because I have the nvidia=true property set in my distrobox.ini file for the box entry in question.
distrobox assemble (and friends) really does a lot of magic to make the experience as user friendly and transparent as possible.
Think about it for a moment. With nvidia=true in place, I can create a fedora-toolbox based distrobox, install the latest version of python (3.14.0a7 is about to drop) and execute a pytorch-based app that needs CUDA that is installed on the host!
Then I can export the python binary to the host and execute the same thing without even entering the distrobox. Finally, I can create a .desktop file (in ~/.local/share/applications) that will allow me to execute that script from the GNOME shell.
# distrobox.ini snippet
exported_bins="/usr/bin/python3.14"
exported_bins_path="var/home/klmcw/.local/bin"
It is just a docker (in my case, podman by default) container - so anything you can do with any other container (like bind mount) can be done with distroboxen.
This is incredibly powerful stuff.
I wrote some tools for myself to help manage distrobox creation. I publish them at:
There is merit to the last statement you make above. But that is just one possibility.
First, you can have multiple distroboxen running. Second, you can have some running with docker and others with podman. Flatpak is a kind of container virtualization technology. And LxC, qemu/virt are enabled by default, as well, at least in the bluefin-dx bootc images.
There are a lot of options for virtualization.
I’ll stop there. I hope I covered the high points of what you are thinking through.
Let me know if you would like to drill down some more.