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

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.

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.

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.

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!

Sylve Dev here! The port is in review and the maintainers has told me that it'll be merged into the next quarterly slush (which is next week). And the installation script on the website will automatically switch to ports when it's available.

Author here: I get where you’re coming from and long term, I agree. I don’t want FreeBSD to slowly turn into "Linux but different."

For me though, the Linuxulator is about practicality today, not philosophy. It lets me use one or two tools (like the VS Code server) without changing how I actually run my system. Everything else stays native FreeBSD.

It's optional, isolated, and doesn't pollute the base system. If native ports exist and work well, I'll always prefer those. But when something critical doesn't, the compatibility layer keeps FreeBSD usable in modern workflows instead of becoming limiting.

So yeah.. I see it more as a bridge, not a direction.

We build and sell multi-service business gateways, basically devices that do networking, VoIP, etc. all in one box. https://difuse.io/ if you're interested!

I'm curious, what hardware would you run it on?

I've been using Zen (https://github.com/zen-browser) for a while now, it's still in beta but is very cool.

This would be awesome if we can export it to plain HTML. Things like the twitter icon doesn't make sense in the PNG that is exported?

I'd want to keep the build step since I may pull markdown from other sources like I think astra allows.

Pushing without building is not a difficult thing to do, in-fact it will make changes much faster too. But you mention pulling markdown files from other places, merge conflicts are bound to happen that way right? And AFAICS there would not be an easy way to manage that automagically without human intervention.

We’re actively working on a feature to support deployment to Git-based repos, including GitHub Pages. Stay tuned!

I don’t think there’s an existing tool that handles Markdown and Git repos without requiring users to interact with Git directly.

We’re currently developing a feature that allows you to push directly to Git from Kalmia. Instead of pushing Markdown, we’ll push the compiled HTML/JS output, eliminating the need for a build step in the Git repo and making CI/CD processes unnecessary.

Thank you for the feedback! I understand the confusion. Kalmia is indeed a server-side CMS, but its Go-based architecture allows it to be lightweight and run on various platforms, from cloud servers to smaller setups like Raspberry Pi.

Think of Kalmia as similar to Docusaurus, but with a built-in GUI—one of the most requested features from the Docusaurus community (https://docusaurus.io/feature-requests/p/make-content-editin...). With Kalmia, non-technical users can contribute to documentation without needing to know Git or Markdown, making content editing much easier.

We store the documentation data in a database (Postgres or SQLite), and markdown/HTML is generated only when updates, deletions, or creations happen. The built HTML is stored in memory for fast access, ensuring performance remains smooth even for large docs.

We’re also working on features like export to zip and GitHub Pages support, so users can host their docs externally if needed.

Regarding SSO, it’s a great suggestion. We’re looking into integrating Single Sign-On (SSO) to streamline user management and improve security. This will help with easier adoption in environments that already use OIDC for authentication. (We already supported OAuth with Github/Microsoft/Google)

Thanks again for your thoughtful input, and I appreciate you checking out Kalmia!

We already load all the documentation assets into memory whenever something changes. Even with large projects spanning hundreds of pages and page groups, it remains very fast—under 1 second in our testing.

That being said, there are some cases where a database is necessary. For example, handling multiple people editing the same document simultaneously wouldn’t work well with just flat files. Also, where would we store user emails/passwords for authentication? Another feature Kalmia supports is private documentation, where users need to log in to access certain docs (there's a simple toggle to enable authentication).

That said, adding an "export to zip" or "push to git" button is totally feasible, and it's something we've had a lot of requests for. While we don't personally use it, we'll be adding it so people can host their docs on static file platforms without needing Kalmia as the backend.

We're using BlocknoteJS it is built on top of prosemirror and tiptap

This is accurate, we also use it for one of our other products here https://docs.difuse.io/, although a demo instance for people to play around with is not a bad idea, will look into that.

Tailwind! And tailwind based component libraries like flowbite made of all these possible.

I actually just discovered Outline yesterday! It's an awesome platform. Our feature set isn't as extensive (yet), especially when it comes to integrations—they've really nailed that. However, many of the other features, like live collaboration and better security, are things we're actively working on and should be available in the next few releases.

One major difference between Outline and Kalmia is the license. I believe Outline uses BSL, while Kalmia is AGPL.