From my experience and reading online, most people suggest spinning up a small Linux vm in bhyve and running docker from it instead of through FreeBSD.

Docker is flawed in a way that by definition it expects to run Linux code. If you run docker on Mac or Windows it actually starts it in a VM.

So with these requirements you can't run it on anything but Linux.

FreeBSD actually has compatibility mode and can run Linux binaries, but why would I want that instead of running a native code?

Because I like FreeBSD and if the kernel's compat layer got the job done, why not?

Well I mean you can run it, I was not even aware there is some effort[1] to run it.

What I was trying to say is that in my opinion this is one of inherent flaws in Docker and I think docker is really a dead end (I'm not talking about dead end of containerization, but just this kind of approach).

What people actually expect from containerization is essentially what Kubernetes is currently providing (quickly spinning new instances of processes, autoscaling, load balancing, rolling updates etc), but I already see questioning why docker is even needed at that point when really cgroups are used to restrict resources and processes already provide enough isolation.

[1] https://wiki.freebsd.org/Docker

It's still experimental:

https://wiki.freebsd.org/Docker

Using FreeBSD as the Docker host requires the Linux compatibility layer, like Windows and macOS.

Windows and macOS literally spin up VMs for Docker - the compat layer in FreeBSD runs binaries natively, just translating syscalls in the kernel.

They used to. The native version has been in beta for a while and it's fairly stable. I've used it locally for about a year.

https://thenewstack.io/native-docker-comes-windows-mac/

No, that literally says they use VMs - they just internally manage them.

Whoops, you're right. They switched from VirtualBox to xhyve on macOS but it's still a VM.

You might also be interested in something better like Project FIFO[1].

[1] http://project-fifo.net