For Jellyfin you will need a VM though, because it does not officially support FreeBSD. In case you need transcoding you should ensure to use the proper CPU type in the VM in case your CPU has hardware support for it.
Which doesn't mean that Jellyfin won't run on FreeBSD out of the box, though. I'd be more concerned with the thumbnail generator middleware's (Skia) screwing up - independend of the OS it's running on - then with Jellyfin itself on FreeBSD. It's a dotnet application and we now have decent dotnet support. Properly providing multimedia content into a true VM instance, rather then a container, is going to come at a significant cost in terms of either performance or setup effort, though.
AFAIK if your CPU isn't properly supported on a FreeBSD host (Intel Core i 12th gen or newer, Xeon Scalable 4th gen or newer, AMD zen4 or newer, ...), then bhyve hosted virtual machines are not going to be able to overcome the host OS's shortcomings, either.
I understand that Docker can not run natively in FreeBSD, but needs to run in a VirtualBox environment. I'm not so fond of VirtualBox, so I was considering how to avoid using this. For the applications currently running in Docker, some of them seem to be docker only installations - such as immich. Some of the others may run natively in FreeBSD - NodeRED, grafana? I need to explore more.
I might be religious here but IMO, if a software cannot be used outside of a Docker Container, then it shouldn't be used in the first place. Docker is supposed to be a containerization solution, not a software distribution solution, and it also lacks most requirements we put into distribution systems. E.g. on Debian, when you deploy a deb package, apt/dpkg will automatically verify the package's cryptographic signature against the pgp credential associated with the repository the package was downloaded from, deb files contain changelogs, apt will tell you what it's going to do besides the deployment order you gave it prior of doing so, it will provide a migration path if your configuration files need modifications, and so on. If you're mistrustive of the stuff debian's providing you, you can check debians' gitlab server and review the CI logs to see what was done in order to build the deb file the CI published (the packages are signed and published by the CI so no debian maintainer could abuse his position to sabotage a package w/o anyone noticing), then make your own decision whether you want to install the debian provided package or build it from source (or apt source) yourself instead. What does docker have to compare? Unsinged SHA256 hashes, no changelog, no migration strategies, image creation intransparence on all major docker registries, ...
If it was just used as a containerization solution and only for that, then the content of the Dockerfile(s) could be turned into a sequence of docker run/copy/mount/... commands on a stateful container, which could then be converted into a sequence of lxc or bastille or raw jail commands if you decided to migrate to another containerization solution. Or you could wrap it all up nicely in ansible or similar orchestration frameworks, to have them either generate the command sequence appropriate for the containerization solution, or generate the Dockerfile / Bastillefile template instead and then invoke docker build / bastille create/template, which scales alot better then handwritten dockerfile stuff, especially if you have a lot of containers.
... which is also what I'd recommend: create some automation that can deploy your debian-based setup completely. Once you have it and you're sure it works, create a virtual machine with FreeBSD on the Debian system and start wrapping the Debian specific commands to enable the orchastration to use FreeBSD codepaths in the VM to do the same thing(s) it does with Debian codepaths on the host. Try getting more and more services that don't hard-depend on Docker into jails, and only when you're done figuring out what services you can't move into jails, and you're still confident you want to make the switch to FreeBSD, reinstall to FreeBSD, pull up a VM with Debian inside on the new FreeBSD installation and run your orchastration for all containers that could go into jails on the host and all those that couldn't go into jail to orchastrate Docker containers into the Debian VM instead.
