> This is kinda like Docker/Podman thing on Linux – but secure instead.
How true is this? I know jails have been around longer than Linux containers, which are explicitly not designed as "secure" isolation (which is why people like fly.io use VMs instead).
How battle-tested are FreeBSD jails?
In particular, I note we're talking FreeBSD, not OpenBSD, which is the one that's all about security.
Sure - lets have a discussion about differences between security of FreeBSD Jails and Linux Podman containers.
Isolation: With rootless Podman it seems to be on the same level as Jails - but only if You run Podman with SELinux or AppArmor enabled. Without SELinux/AppArmor the Jails offer better isolation. When you run Podman with SELinux/AppArmor and then you add MAC Framework (like mac_sebsd/mac_jail/mac_bsdextended/mac_portacl) the Jails are more isolated again.
Kernel Syscalls Surface: Even rootless Podman has 'full' syscall access unless blocked by seccomp (SELinux). Jails have restricted use of syscalls without any additional tools - and that can be also narrowed with MAC Framework on FreeBSD.
Firewall: You can not run firewall inside rootless Podman container. You can run entire network stack and any firewall like PF or IPFW independently from the host inside VNET Jail - which means more security.
TL;DR: FreeBSD Jails are generally more secure out-of-the-box compared to Podman containers and even more secure if you take the time to add additional layers of security.
> How battle-tested are FreeBSD Jails?
Jails are in production since 1999/2000 when they were introduced - so 25 years strong - very well battle tested.
Docker is with us since 2014 so that means about 10 years less - but we must compare to Podman ...
Rootless support for Podman first appeared late 2019 (1.6) so only less then 6 years to test.
That means Jails are the most battle tested of all of them.
Hope that helps.
Regards, vermaden
Linux containers are also fairly secure, even though that isn’t their explicit purpose. Container escape bugs are CVEs and are fixed immediately.
The line is just tribalism shade.
It probably has its advantages but until the UX reaches what we get with “docker run” this technology will never achieve its potential. When developing we need to think not only about what is possible but also how people do things currently and how does that compare to what we are proposing in terms of ergonomics. How many commands to get from 0 to hero with incumbent solution? How many with proposed solution? You get the point.
I personally really like Bastille for jail management. It's way more ergonomic than creating jails by hand and allows you to focus on the stuff running in the jails rather than the jails themselves.
I believe FreeBSD has podman running on top of jails now, so that should... exist? I mean, you can still run jails directly like this, but the days of `podman run` are either here or imminent.
docker run is broken as of April 1, 2025
https://docs.docker.com/docker-hub/usage/
100 pulls per 6 hours. I think each base layer counts. Also may have troubles with ip4 reuse. It was bad enough they delayed it a month: https://www.theregister.com/2025/02/22/docker_hub_pull_limit... https://github.com/search?q=%22docker+pull%22+limit&type=iss...
Better to use podman and build your own containers from Containerfile/Dockerfile (your own or open source ones, there are a ton on GitHub/GitLab/Codeberg that you can build yourself) and base layers.
That's not "broken". Docker Inc. is just rate-limiting access to their service. A service which, for what it's worth, has been used to bootstrap the technology required to sustain a pile of money for a lot of people.
There are other container repositories, and as you said, you can build your own containers and run those.
It's a dependency bottleneck that requires a pretty hefty amount of money ($9/mo) to get around
You can just host your own registry, or use a managed one like AWS ECR (which has a pretty good free tier).
[deleted]
One can use Google as a proxy, it isn't rate limited afaik
https://cloud.google.com/artifact-registry/docs/pull-cached-...
> Minecraft Server
Worthy to note here: Minecraft JAVA server. Not the Minecraft Bedrock server, which can run natively on Linux.
> but secure instead
Can you provide proof? It feels like an empty statement.
Since there is not native (or source code) for Minecraft Bedrock for FreeBSD you can run Bedrock Minecraft server on FreeBSD using Linux Jail - with Linux Binary Compatibility FreeBSD feature.
Details here:
- https://forums.freebsd.org/threads/minecraft-bedrock-edition...
> Can you provide proof? It feels like an empty statement.
Here:
? why can't the java server run natively on linux?
I would presume they are talking about how Java is executed by the Java language's Java VM while Bedrock is compiled C++ code?
Jail are not more secure than Linux containers.
You will need to back that claim up with a long list of facts.
The article backed that claim with zero facts, the GP responded in kind. This seems to be pretty fair.
Not to be picky, but they could be on a par. There doesn't have to be a massive difference in this regard. Jails are well established, and well understood. I prefer BSD solutions and I run jails and Linux kvm.
Jails have been around longer, but I'm not sure how much it really matters. Jails and containers both share the kernel across workloads. A kernel exploit is generally accepted as the barrier to break out (and of course implementation bugs). VMs don't share kernels across workloads, but do share a hypervisor which can also have breakout bugs. Both jails and containers depend on the kernel to be bug free.
VMs (depending on hypervisor) are easier to secure by default, you can't easily forget an overlay fs, or make other mistakes that expose some part of the host to containers.
Here is my take on that topic:
Wow, you sure convinced me
Why is the container jailed by the Minecraft server? How can something called Free BSD have a jail?
[deleted]