Sylve – Proxmox Alternative by FreeBSD
sylve.io
sylve.io
This is awesome! I only started toying around with Proxmox after VMware became actively hostile towards users last year or maybe a bit earlier. This is a welcome alternative in the space. It's impressive. But the reputation of FreeBSD and the inclusion of ZFS and jails from the people I trust most to build a lightweight system is pretty great and I'm excited to see how this develops over time.
No, it is not.
FreeBSD are listed as ONE of the three core sponsors.
The other two are commercial organisations.
The GitHub repo is not hosted by FreeBSD either, it is by one of the other sponsors, "AlchemillaHQ".
There is nothing "by" about this.
"for", sure, but "by", nope.
I know we have cockpit but it never really clicked for me. Functionality wise too crashy and not so nicely intergrated, design wise it has the information density of a grandparent brick phone.
You do know Proxmox is a fancy UI on top of Debian, right ?
The entire Sylve bundle (backend + frontend) is ~55 MB, fully self-contained, and doesn’t mess with the base system in any destructive way. You can drop it in and remove it cleanly.
Proxmox, on the other hand, replaces core parts of the system, including the kernel, and its package ecosystem diverges quite a bit from standard Debian. I’ve tried using it on a desktop before and rolling that back cleanly isn’t exactly straightforward.
At that point it’s more of a tightly coupled platform built on Debian than just “a UI on top,” especially when the underlying system is no longer behaving like Debian in the usual sense.
Well, sure, but Proxmox was never intended to be a desktop solution.
It was always intended as a server solution, installed on bare-metal, and therefore "rolling-back" is a re-format and re-install (or shredding the drives if the server is being decommissioned).
If the expected recovery path is “wipe and reinstall,” then it’s clearly not just a thin layer on top of Debian. It’s effectively its own platform with its own assumptions, lifecycle, and upgrade path.
There’s nothing wrong with that, but it’s a very different model from something that can coexist with or cleanly detach from the base system. That distinction matters depending on how people want to use it, especially outside of a dedicated bare-metal server context.
So yeah, Proxmox is built on Debian, but in practice it behaves more like a tightly integrated appliance than a simple UI sitting on top.
I originally started Sylve with an OpenWRT/LFS mindset since I had a lot of experience there. But even then, Linux often feels a bit cobbled together. ZFS is awkward because of the GPL vs CDDL situation, userland and kernel development feel disconnected, and there are so many different ways to do the same thing. I won’t even get into systemd, you get the idea.
What really clicked for me was using a system where the kernel and userland are developed together. That cohesion makes a big difference. Technically, I was able to rely almost entirely on the base OS without pulling in extra dependencies, aside from libvirt to make migration easier and Samba for file sharing.
Going forward, Sylve leans into that even more. PF for the firewall, the rock solid iSCSI implementation in base, even things like smart(8) written by src committers just feel more consistent and thought through.
So yeah, Debian definitely wins on features and applications. But for me, FreeBSD wins on coherence and design.
Now we only need Sylve Community Scripts! Although creating a new jail (I guess FreeBSD alternative for LXC containers?) doesn't seem difficult.
Another underrated part of FreeBSD is pkg. It’s often simpler than Linux package management. For example, installing Jellyfin on Debian or Ubuntu means adding a third party repo and dealing with updates, but on FreeBSD it’s just `pkg install jellyfin`. With pkgbase, even system updates are simple, just `pkg update && pkg upgrade` and you’re done, without worrying about breaking your system.
If this can be documented, and work with an exterior common pkg repo state, then every jail can be updated on pkg upgrade, for it's specific pkg, when the exterior state is updated for pkg update, to get refreshed for what needs to be updated.
Right now, under bastille, I do pkg update && pkg upgrade inside each jail and I therefore have n copies of the state of the pkg repo.
Trivial attempts at this wind up with every jail having identical pkg state. I don't want that: one for plex, one for vaultwarden, one for adguard, they should have the minimum attack surface of just the pkg and the necessary dependencies.
I've been experimenting with jails on my devserver to sandbox AI agents, going to give this a whirl.
Jails are great if your packages are in ports, and if not, Linux jails work well too: https://sylve.io/guides/deployments/rocky-linux-jail/, Haven't hit a CLI app that doesn't run in a FreeBSD Linux jail yet!
It is not "by FreeBSD".
The GitHub repo is "AlchemillaHQ" who are one of the three sponsors of the project.