FreeBSD OCI Containers

rxc1441

rxc1441

I'm building my first freebsd oci containers with Podman and so far the builds look good.

Unfortunately FreeBSD is not supported on https://quay.io - do we just develop on DockerHub in the mean time or will there be an official FreeBSD container registry

Robert
 
I noticed a break in the CI/CD pipeline from source tree upstream on my fork builds. These are the cross-build kernel workflows on GitHub.

Has anyone proposed official FreeBSD containerization development here vs Ubuntu containers at upstream source tree development.

Ubuntu containers are awesome but FreeBSD containers should be de facto logically I’d say.

This is an automation bot I have been developing. I guess I can mention Potatobot now. The motivation or Unix inspired philosophy if you will is - “CI/CD powered by a potato.”

github.com

GitHub - rcghpge/freebsd: FreeBSD source

FreeBSD source. Contribute to rcghpge/freebsd development by creating an account on GitHub.
github.com github.com
 
All this talk of containers makes me think it's a "me too" cause Linux has it and not because we don't have our own thing and it's just a Linux-ism.
 
We could build our own essentially. ocijails was developed in the community. If I would build cloud orchestration for cloud computing I’d start with jails, Poudriere, ocijails, Podman, native FreeBSD runtime, to name a few build concepts.

Is there a better solution here in this space by chance

ocijails
github.com

GitHub - dfr/ocijail: An OCI runtime using FreeBSD jail

An OCI runtime using FreeBSD jail. Contribute to dfr/ocijail development by creating an account on GitHub.
github.com github.com

I was able to catch a jails meeting call and one of the greybeards recommended I look into qubsd

See post here
Thread 'quBSD - A New Jails and bhyve Wrapper That Emulates Qubes'
https://forums.freebsd.org/threads/qubsd-a-new-jails-and-bhyve-wrapper-that-emulates-qubes.83994/

From there we can just run plug and play for native OCI runtime vs native FreeBSD runtime

FreeBSD Officially Supported in OCI Runtime Specification v1.3 | FreeBSD Foundation

FreeBSD has been included as an officially supported platform in version 1.3 of the Open Container Initiative (OCI) runtime specification, released November 4, 2025. This milestone marks a significant achievement for FreeBSD and represents years of dedicated work by volunteers in the community...
freebsdfoundation.org freebsdfoundation.org
 
Last edited:
So what OCI Image do I need? I can't find anything explaining the differences between these:
  • freebsd-runtime
  • freebsd-toolchain
  • freebsd-static
  • freebsd-notoolchain
  • freebsd-dynamic
Lets say I need to install a package and run a build as part of a CI/CD pipeline.
 
The official FreeBSD images have been renamed, but for some reason the person publishing did not supply a description in the 'Overview'. Perhaps this can be corrected along with some actual documentation in the Handbook. I know this work has to be done by volunteers but it really does need at least some rudimentary documentation from those that built these tools so that others can improve the documentation after they have gained a working knowledge.

FreeBSD

Discover official Docker images from FreeBSD, an Open Source publisher on Docker Hub. Visit their profile and explore images they maintain.
hub.docker.com hub.docker.com

The previous image descriptions are described in https://freebsdfoundation.org/freebsd-container-images/ . The image sizes are a clue to how much functionality they have.
  • “static” which contains just SSL certificates and timezone data. This can be used as a basis for statically linked applications.
  • “base” which extends “static” by adding a selection of shared libraries to support a wide variety of dynamically linked applications
  • “minimal” which adds the FreeBSD-runtime package and package management as before
  • “small” which adds FreeBSD-utilities for broader support of shell-based applications.
I have been an early adopter/experimenter of Podman OCI Containers on FreeBSD but I could never quite achieve what I needed to do to use them instead of jails or porting existing Linux Docker containers to native FreeBSD versions. I either went back to building a FreeBSD jail or using Docker on Linux. The main reason being for this was a lack of good official documentation in the FreeBSD Handbook, particularly when it came to networking and firewalling.

However, I have recently found a project that appears to have leapfrogged the official effort. I am sure you will find that the Daemonless project will be of use to you. I will be giving FreeBSD Podman another go now that Daemonless have solved my problem with undocumented FreeBSD container networking.

daemonless.io

Daemonless Philosophy: Bringing Modern DevOps to FreeBSD - daemonless

Discover why we built Daemonless. We are bridging the gap between the stability of FreeBSD Jails and the convenience of OCI containerization for developers.
daemonless.io daemonless.io

One thing that is noticeably different is 'dbuild' which I will have to learn. I am comfortable with Dockerfile/docker-compose/Scout and liked Podman because moving from Docker appeared to be easy and trouble free, it is not. There are similarities, but it does require spending time to learn the differences and accept them. I am sufficiently open minded to give dbuild a chance and stray outside of my comfort zone on Docker. If dbuild is the tool to make FreeBSD Podman work well, then I need to try it.

daemonless.io

dbuild: The Universal Build Engine for FreeBSD OCI Containers - daemonless

Master the full lifecycle of FreeBSD OCI images with dbuild. Automate native builds, cumulative integration tests, SBOM generation, and multi-arch registry pushes.
daemonless.io daemonless.io

If like me you like to read Docker files to see how a container is built, there does not appear to be any in the Daemonless container builds. I will have to learn how this works as I don't like the idea of not knowing what is actually inside my containers. There is a sbom.json published in each of their container repos which is informative but I can't see the sequence or how config files are added. I guess it will be some time before vulnerability analysis tools will be available to read the SBOM.
 
Hey everyone, hope all is good. I am wrapping up my FreeBSD OCI container builds. I was able to build complete OCI containers but I had dual boot issues with native Linux and native FreeBSD dual booting on my machine. But I have a basic FreeBSD 16.0 OCI container that can be scaled from GitLab. I have a Debian OCI container as well (I know I know).

These are for project requirements for deployment in uni.

Edit. New GitLab handle
 
Last edited:
I think I want to rewrite this repository since the semester concluded. Debian is a solid Linux distribution imho. Maybe I’ll test a Linuxulator bridge or something for jails.
 
rxc1441 said:
We could build our own essentially. ocijails was developed in the community. If I would build cloud orchestration for cloud computing I’d start with jails, Poudriere, ocijails, Podman, native FreeBSD runtime, to name a few build concepts.

Is there a better solution here in this space by chance

ocijails
github.com

GitHub - dfr/ocijail: An OCI runtime using FreeBSD jail

An OCI runtime using FreeBSD jail. Contribute to dfr/ocijail development by creating an account on GitHub.
github.com github.com

I was able to catch a jails meeting call and one of the greybeards recommended I look into qubsd

See post here
Thread 'quBSD - A New Jails and bhyve Wrapper That Emulates Qubes'
https://forums.freebsd.org/threads/qubsd-a-new-jails-and-bhyve-wrapper-that-emulates-qubes.83994/

From there we can just run plug and play for native OCI runtime vs native FreeBSD runtime

FreeBSD Officially Supported in OCI Runtime Specification v1.3 | FreeBSD Foundation

FreeBSD has been included as an officially supported platform in version 1.3 of the Open Container Initiative (OCI) runtime specification, released November 4, 2025. This milestone marks a significant achievement for FreeBSD and represents years of dedicated work by volunteers in the community...
freebsdfoundation.org freebsdfoundation.org
Click to expand...
We should not use podman.
 
We should not use podman.
Click to expand...

I will have to disagree with you on that

Podman on Freebsd allows you to run Linux applications with Cuda

like the following

Davinci Resolve
ComfYU
demucs audio separation
kokoro-onnx
WhisperX audio transcription
Ollama
Blender

github.com

GitHub - NapoleonWils0n/freebsd-cuda: Run Linux command line and gui applications on FreeBSD with full Nvidia Cuda hardware acceleration.

Run Linux command line and gui applications on FreeBSD with full Nvidia Cuda hardware acceleration. - NapoleonWils0n/freebsd-cuda
github.com github.com

github.com

GitHub - NapoleonWils0n/freebsd-nixpkgs: Nixpkgs Podman containers on Freebsd with home-manager and flakes

Nixpkgs Podman containers on Freebsd with home-manager and flakes - NapoleonWils0n/freebsd-nixpkgs
github.com github.com

With Podman you can specify the os as linux
This lets applications see a real linux environment

If you try and build python applications in a linux jail
they can detect they are running in a linux jail on freebsd
through sys calls and will try and pull down freebsd wheels that dont exist

but if you use a linux podman container they will pull down the linux wheels
because using os linux tricks them into thinking they are running on real linux
 
You must log in or register to reply here.
Back
Top