Yeah, I’m kind of in the same camp. I never really had issues with systemd either. It mostly just works, even if it’s a bit heavy.
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.
Author of Sylve here, and I helped deploy the setup in the post.
> All I read is that they are still doing ClickOPS over DevSecOps!!
Their setup is mostly working on embedded stuff, and this involves some amount of moving VM disk images around, sometimes they run different software within the same VM disk, so that means ZFS properties need to be tweaked accordingly (compression, recordsize, etc). This is a lot easier to do with a UI than it is with CLI, and the UI is pretty good at showing you what’s going on. Now I'm all for automating stuff, but there's no clear pattern here to automate away,
Now regarding automation in Sylve, you can create a template out of Sylve (with networking, storage, CPU config etc.) and then deploy that template as many times as you want (from the UI), last I checked proxmox only allows you to clone from template one at a time.
What I do is pretty similar to what you mention, but I don't really use ansible since on FreeBSD if it's in the ports tree its one command (after base system is set up) which is `pkg install -y <package>`. And your entire stack (from your list), can be done with one command each. The only thing I see that would need a bit setup would be the wireguard vpn, but even that is pretty straightforward under FreeBSD (so you can do it with a jail and no need for a VM).
I see, based on your comment and others, Sylve seems to be heavily GUI for everything.
There is nothing wrong with that but if an user cannot perform the same tasks via CLI, I see that as a big blocker for a project to be fully adopted with exceptions. OPNSense, there is zero reasons to manage the whole network and what not via CLI, GUI makes life so much easier. I would hate it having to do everything via CLI.
The other thing is LXC, Sylve seems to call it jail.
I would expect this jail to support something like below.
Ansible only automates what you do manually, the server itself only sees the command and it will never run Ansible itself, so intead of manually creating a LXC, Ansible would send:
All of that from my PC without having to go to a browser. That is the friction that your team should look into automating, there is always a way, it is just easier to go to the browser.
We’re API-first, the UI is just a client on top. We already ship Swagger docs with the code (docs/ on the repo), so everything the UI does is exposed and usable programmatically today.
Right now we’re still early (v0.2), so the CLI/SDK pieces aren’t fully there yet, but that’s what we’re building next.
Before v0.4 the plan is:
* a proper CLI for scripting
* a well-defined API lib (TypeScript/Go first, others later)
OP here. It’s less about Sylve doing something Proxmox can’t do, and more about a bunch of QoL improvements that come from us being heavy Proxmox users and building what we felt was missing.
A few concrete things:
ZFS-first UX: Not just "ZFS as storage”, but everything built around it. Snapshots, clones, ZVOLs, replication, all cleanly exposed in the UI without dropping to CLI.
Simple backups without extra infra: Any remote box with SSH + ZFS works. No need to deploy something like PBS just to get decent backups.
Built-in Samba shares: You can spin up and manage shares directly from the UI without having to manually configure services.
Magnet / torrent downloader baked in: Sounds small, but for homelab use it removes a whole extra container/VM people usually end up running.
Clustering: but not all-or-nothing, You can cluster nodes when you need it, and also disable/unwind it later. Proxmox clusters are much more rigid once set up.
Templates done right: Create a base VM/jail once and spin up N instances from it in one go, straight from the UI.
FreeBSD base: It's not really a benefit of Sylve, but rather the ecosystem that FreeBSD provides.. Tighter system integration, smaller surface area, no systemd, etc. (depending on what you care about)
None of this is to say Proxmox is bad, it’s great. This is more "we used it a lot, hit some friction points, and built something that feels smoother for our workflows."
I get the impression bhyve does all that stuff too. Is sylve basically just a thin GUI wrapper on top?
(That'd be amazing if it's possible to do stuff like dump configs + check them into git from the cli, then stand them up on any bhve/sylve box later...)
That’s true, bhyve doesn’t support nested virtualization right now.
In practice though, most setups don’t actually need it if you’re running workloads directly on the host.
Also, if your goal is testing or simulating clusters, you can already run Sylve inside jails. That gives you multiple isolated “nodes” on a single machine without needing nested virt. We have a guide for it here:
https://sylve.io/guides/advanced-topics/jailing-sylve/
So you can still experiment with things like clustering, networking, failure scenarios, etc., just using jails instead of spinning up hypervisors inside VMs.
Nested virt is still useful for specific cases like testing other hypervisors or running Firecracker inside VMs, but for most Sylve-style setups it hasn’t really been a blocker.
OP here. One thing we mentioned in the blog but probably didn’t emphasize enough is how deeply ZFS is integrated into the UI.
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.
I did actually notice the ZFS gui which is indeed something lacking in proxmox which doesn't default to ZFS in the installer. However once you do install it using ZFS it actually makes use of it pretty well and the user does not need to mess with the zfs cli tools much. Obviously it would be nice to have a GUI for all zfs operations too. Then again even TrueNAS refers you back to the cli for SOME operations.
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.
I just installed Proxmox for the first time with a 5 disk ZFS array. Very basic stuff but I already had to go to the CLI a few times and it didn't really feel that well integrated. Even setting up the array didn't work (non-descript -1 error message, and ended up needed to use -f on the cli). I also couldn't find a zfs create equivalent (but that could have been me?)
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.
Yeah, that’s pretty much been my experience as well. Last time I seriously used Proxmox with ZFS (I think 8.4.x), it felt a bit… bolted on.
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.
Do you have any opinions on how this works vs doing iSCSI to some other storage system using ZFS? That's how I've been handling Proxmox on the backend, and have mixed feelings. The GUI leaves a very great deal to be desired in honestly curious ways, have to touch the CLI a lot even for super basic networking or auth stuff, and of course neither side has the same insight to the data structures in question. Either you've got to do ZVOL instances and thus manual effort or scripting, or you give Proxmox a single big blob then let it manage that with LVM but that means the storage side can't give any granular help on snapshots and the like. It still can deal with data integrity and backups and storage redundancy and all that but no further, and some increased overhead. But on the other hand, I do feel like a really firm separation of concerns isn't without value. Having native support though is an interesting alternative I hadn't really considered.
Too late to edit, but just as a note for anyone else who gets confused by my post: I was not paying careful enough attention and missed/misread the "backups" bit in the parent post, completely my fault. As far as I can tell from reading through the (quite pleasant!) documentation [0], Sylve does not (at least for now) support any sort of network storage for direct use as the VM backing store, though as it is FreeBSD underneath it's presumably doable to get something going from the command line. I'd thought they'd somehow managed to set something up so you could directly use another ZFS system via SSH as the primary backing store with management which would be pretty awesome. It still looks like a beautiful design, but since I'm pretty invested right now in separating out storage into its own hardware vs where compute happens it'd be hard to setup nodes as AIO for the near future at least here.
Still an awesome project to learn about and I hope it's successful.
It's funny, I love how FreeBSD manages iSCSI even though I have only used it a few times, I put it in my to-do list but never really got around to writing a UI for it. Come next release (v0.3.0) I will definitely integrate it because as your put it's quite necessary to have that as a way to isolate storage from the main system.
LXCs are pretty similar to jails, and Sylve makes them really easy to use. One nice trick is that you can template a base jail and clone it any number of times straight from the UI, no need to drop into a shell and script it like I used to.
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.
One problem with pkg and jails, is that there aren't good instructions for how you separate the "this is the current list of pkg and their status in the repo" from "this is the current list of INSTALLED pkg and their specific state and version in this host"
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.
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.
> I’ve tried using it on a desktop before and rolling that back cleanly isn’t exactly straightforward.
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).
That’s fair, but that kind of reinforces my point.
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.
Well said, you get what I'm looking for. This might be the reason for me to give freebsd a go. Though my current hardware probably wouldn't play nice with it.
It’s kind of funny, Debian was my distro of choice since I was 15, so about 10 years up until last year. I still envy its huge application ecosystem. But over time I’ve come to really appreciate simplicity and the principle of least astonishment.
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.
I would've given up on this project without Svelte 5! It’s so hard to justify React after using it. Proxmox always felt sluggish, but Sylve with Svelte stays smooth even on large clusters. DX is also much better. We started on Svelte 4 but moved early to 5 for things like runes.
reply