arch1e

As someone who tried to build a fairly large project with HTMX + Go, I can say it just wasn't there for me. Maybe it will get there eventually, but I'm not convinced.

For simple CRUD apps and admin dashboards, HTMX is great. But once you have lots of interconnected components, shared state, and complex interactions, managing everything quickly becomes difficult.

I originally chose HTMX because I really didn't enjoy working with React. Eventually I tried SvelteKit, and it completely changed my perspective. I still use Go for the backend, but SvelteKit in SPA mode for the frontend. It gives me a clean separation between the two while making complex UIs much easier to build and maintain.

What really sold me was that Svelte feels like a natural extension of HTML rather than a different language with JSX. State management is simple, the component model is intuitive, and the new `$state` syntax is especially nice.

Yes! We're planning out terraform provider, It should land in v0.2.5, we're at v0.2.3 now.

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.

That’s fair, but Sylve isn’t GUI-only.

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)

* parity between UI, CLI, and API

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.

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).

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."

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.

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.

It’s not really just a fancy UI though.

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.

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.