Sylve looks like a decent project with a promising future but this article really doesn't explain why they picked it over Proxmox at all. They explain a lot of things but I can't see the advantage over prox other than they wanted to use it.
With Sylve, you rarely need to touch the CLI. Snapshots, datasets, ZVOLs, even flashing images directly to ZVOLs, it’s all handled from the UI in a straightforward way.
That tight ZFS integration also lets us build more flexible backup workflows. You can back up VMs, jails, or entire datasets to any remote machine that supports SSH + ZFS. This is powered by Zelta (https://zelta.space) (which is embedded directly into the Go backend), so it’s built-in rather than something you bolt on.
In Proxmox, you can achieve similar things, but it’s less intuitive and usually involves setting up additional components like Proxmox Backup Server.
Still an awesome project to learn about and I hope it's successful.
----
On proxmox ZFS syncs do not require proxmox backup server, which actually has its own format which is very efficient in speed and disk space, but you do either need something like sanoid/syncoid or use of the shell.
It's fine because I'm comfortable in the CLI but I read your comment and wanted to share that it felt a bit rudimentary at best.
It works fine for the common VM workflows, but once you step outside that path, you end up dropping to the CLI more than you’d expect.
In Sylve, we tried to make ZFS a first-class part of the system rather than something sitting underneath it. You can create pools, scrub them with actual progress visibility, replace disks, and manage datasets (Filesystems, Volumes, Snapshots) directly from the UI.
Proxmox tends to abstract datasets away and handle them for you, which is great for standard VM usage, but gets limiting if you want to do something custom, like creating your own dataset for media or Samba shares.
That’s really where Sylve differs, it gives you both the "it just works" path and the flexibility without forcing you into the CLI.
A huge, totally obvious, advantage is that FreeBSD isn't using systemd. I'm now nearly systemd-free, if not for Proxmox. But my VMs are systemd free. And, by definition, my containers too (where basically the entire point is that there's a PID 1 for the service and that PID 1, in a container is not systemd).
So the last piece missing for me is getting rid of Proxmox because Proxmox is using systemd.
I was thinking about going straight to FreeBSD+bhyve (the hypervisor) but that felt a bit raw. FreeBSD+Sylve (using bhyve under the hood) seems to be, at long last, my way out of systemd.
I've got several servers at home with Proxmox but I never, on purpose, relied too much on Proxmox: I kept it to the bare minimum. I create VMs and use cloudinit and tried to have most of it automated and always made it with the idea of getting rid of Promox.
I've got nothing against Proxmox but fuck systemd. Just fuck that system.
What about performance characteristics? Recoverability of workloads?
I’m interested in a FreeBSD base OS because it seems ZFS is better integrated and ZFS has a lot of incredibly useful tools that come with it. If Bhyve is at least nearly as performant as KVM, I’d be hard pressed not to give it a whirl.
I've been repeatedly burned by systemd, both on machines I've administered and on appliances. In every situation, the right fix was either "switch distros" or "burn developer-months of work in a fire drill".
In fact, I just decided to go with FreeBSD instead of proxmox specifically because proxmox requires systemd. The last N systemd machines I've had the misfortune to touch were broken due to various systemd related issues. (For large values of N.)
I assume that means anything built on top of it is flaky + not stable enough for production use.
For me, moving to FreeBSD wasn’t about escaping systemd, it was more about the overall system design and how cohesive everything feels. That said, I’ve tried to keep Sylve neutral on that front. I don’t really position it as “systemd vs not”, just focus on what it actually does well.
It’s still early and not as feature complete as Proxmox yet, but I think it already stands on its own as a solid option.
I managed the distro upgrade on hundreds of remotely-managed nodes, porting our kiosk appliance from a pre-systemd debian to a post-systemd debian, and out of all the headaches we suffered systemd was not one of them, short of a few quirks we caught in our development process. It pretty much just worked and the services it provided made that upgrade so much easier.
Curious how you got burned, I hear a lot of complaining but haven't seen a lot of evidence
I have quite a lot of customers that we have migrated from VMware to Proxmox. Some of them are rocking zfs instead of vmfs. Mostly these are Dell servers. Proxmox with zfs seems to be more aggressive about disc failure warnings, which I think is helpful.
Pick what OS works for you.
I run Proxmox at home, but now that I have been drinking the NixOS koolaid over the past 2 years, all of my homelab problems suddenly look like Nix-shaped nails.
I actually have a few hosts that only run docker. I might be able to test with those.
Looks like Nix will eat the world soon. :)