Sylve puts Bhyve, Jails, ZFS and PF behind a web interface on FreeBSD

One panel for the FreeBSD subsystems that normally need separate tools

Sylve is an open source infrastructure management platform built for FreeBSD. Its pitch is consolidation: Bhyve virtual machines, FreeBSD Jails, ZFS storage, networking, firewalling, backups and clustered operations sit in one modern web interface rather than being scattered across subsystem tools.

The scope is broader than a hypervisor GUI. The features table in the README breaks the platform into five areas. Virtualization covers Bhyve VMs, Jails, templates, snapshots, consoles, passthrough and staged migration. Storage covers ZFS management, backups, early-access replication, S.M.A.R.T., Samba and iSCSI. Networking covers switches, VLANs, DHCP, routing, the PF firewall and NAT, WireGuard and mDNS. Security and services add authentication, certificates, Let's Encrypt, Dynamic DNS, notifications and auditing. Operations adds clustering, dashboards, telemetry, workload activity, plus local CLI and console tooling.

That list tells you who the audience is. A single administrator or small team running a FreeBSD box that hosts VMs, jails and storage would otherwise juggle bhyve(8), jctl(8), zfs(8), pfctl(8) and the WireGuard tooling separately, each with its own configuration format and its own idea of how a service should be reloaded. Sylve's value is that one UI owns the whole node, and clustering means several nodes can be managed together.

The README frames the project as a streamlined, FreeBSD-native alternative to managing each subsystem by hand, and that alternative is the honest comparison. Manual FreeBSD administration is not missing features, it is missing coherence.

A Go backend compiled for freebsd talks to SvelteKit in the browser

The architecture is a Go backend with a SvelteKit frontend, and the repository layout reflects a two-part codebase. The top level holds cmd/ for the binary entry point, internal/ for the service layer, pkg/ for reusable packages, web/ for the frontend, scripts/, third-party/, docs/, and a config.example.json at the root. The Go module is github.com/alchemillahq/sylve and it targets Go 1.25.0.

The dependency list says more about what Sylve actually does than the feature table does. libvirt access comes through github.com/digitalocean/go-libvirt, and hashicorp/raft plus raft-boltdb are present for the clustering feature, which is a consensus layer rather than a simple peer list. Networking is handled with vishvananda/netlink, google/gopacket and miekg/dns, so packets and DNS are managed at low level. wireguard is a direct dependency, so tunnels are configured in process rather than by shelling out to wg(8). Storage goes through github.com/alchemillahq/gzfs, a project specific ZFS binding, and github.com/dgraph-io/badger/v4 provides a key value store, with mattn/go-sqlite3 also listed for the database side.

The Go module file also declares ignored directories: docs, web, assets and internal/testutil are excluded from the module, which is a hint that the frontend and some test helpers are managed outside the Go build.

Authentication deserves a mention. The dependency list includes golang-jwt/jwt/v4 for tokens, go-webauthn/webauthn for passkeys, msteinert/pam for local system authentication and go-playground/validator for request validation. The service runs on gin-gonic/gin, with gzip and static file serving from the gin-contrib packages.

pkg install sylve, then service sylve enable and service sylve start

Installation is a package operation on FreeBSD. The quick start is three commands:

pkg install sylve
service sylve enable
service sylve start

The first line installs the package, the second makes the service start at boot, and the third starts it now. The alternative route is the Ports Collection:

cd /usr/ports/sysutils/sylve && make install clean

After that, open the web interface at https://<host>:8181. The port and the scheme are the important operational details here. The interface is served over TLS on a non-standard port, so access rules and reverse proxy configuration need to account for 8181.

Credentials deserve a careful read. A fresh package installation uses admin as both the username and the password, and the README says to change these credentials before exposing the node to an untrusted network. That is a default credential with full control over virtualization, storage and firewalling, so treating the first login as a provisioning step rather than a demo is the right posture.

For anything beyond the quick start, the documentation points to the Getting Started guide for installation details, dependencies, configuration and first workload guides.

libvirt 12.5.0 and a ZFS pool decide which features you can use

The requirements section sets the real boundaries on what Sylve can do on a given host. The baseline is FreeBSD 15.0 or newer with a configured system hostname. A ZFS pool is required when managing virtual machines or Jails, and ZFS remains recommended for other deployments. libvirt 12.5.0 or newer is required when managing virtual machines, while Jail-only and non-virtualization installations do not require libvirt.

That third point deserves attention. It means the libvirt dependency is a consequence of the Bhyve feature set, not a base requirement of the platform. A team that only wants Jails, ZFS, Samba, iSCSI and network configuration can run Sylve without libvirt at all, and that is the deployment to prefer if you have no intention of running VMs.

The Makefile shows the same split in the build configuration. The backend target compiles with CGO_ENABLED=1 and GOOS=freebsd, with ARCH defaulting to amd64 and FREEBSD_VERSION defaulting to 15. It also handles an architecture specific constraint: libutp's mmsg dependency lacks FreeBSD/arm64 support, so on arm64 the build tags become nosqlite,disable_libutp instead of just nosqlite. That is a small window into the kind of detail a FreeBSD-only tool has to carry, and it also means the arm64 build drops the sqlite driver.

The release picture matches a project that ships a rolling channel. Recent tags include a tip release described as a rolling build, plus v0.3.1 on 2026-09-07 and v0.3.0 on 2026-08-24. The repository is not archived and the last push was on 2026-10-19, so the codebase is moving quickly and the version numbers are still low.

S.M.A.R.T. self-tests run under their own make targets and timeouts

The storage and diagnostics side of Sylve is backed by dedicated tooling in the build system, and the Makefile shows how a lot of it is exercised. S.M.A.R.T. integration has its own target, test-smart-integration, with configurable behaviour rather than fixed values.

The variables tell the story. SMART_DEVICE is empty by default, so you have to point the test at a device. SMART_RUN_SELF_TEST defaults to 0, meaning the self test is opt in. SMART_WAIT_SELF_TEST also defaults to 0, and the log destination is tmp/smart-integration.log. Timeouts are generous and explicit: SMART_TEST_TIMEOUT defaults to 30m and INTEGRATION_TEST_TIMEOUT to 45m. The existence of a dedicated timeout for a drive self test reflects how long a S.M.A.R.T. long test can legitimately take.

Beyond that, the Makefile lists a set of integration packages that map closely onto the feature areas: console, downloadstorage, mountutil, and services for disk, iscsi, jail, libvirt, migration, network, cluster, zelta, utilities and zfs, plus zfsutil and the network packages bridgevlan and mdns. There is a separate acceptance package at ./internal/console/integration, and the target list distinguishes test-integration, test-vlan-integration, test-acceptance, test-acceptance-full and test-acceptance-all.

The build also has quality targets, quality and quality-fix, alongside a csmwrap target and csmwrap-assets that the backend target depends on. For an engineer evaluating whether this can be part of a CI pipeline, the presence of granular acceptance and integration targets is a better signal than the release cadence.

Early-access replication and audit trails are the features to probe first

Two items in the feature list carry qualifiers that a careful buyer should note. Storage management includes early-access replication, and the qualifier is the point: this is preview quality, and the documentation does not describe a support commitment for it. The security and services area lists auditing alongside authentication, certificates, Let's Encrypt and Dynamic DNS, but the README does not specify what is recorded, how long it is kept, or whether the log is tamper evident. If compliance reporting is your reason for buying a management plane, that is a question to ask the project rather than a feature to assume.

Clustering is the other area where the marketing phrase outruns the description. The dependency list shows hashicorp/raft with a BoltDB backend, which points to a replicated state machine rather than a loose collection of agents, and the operations row lists clustering, dashboards, telemetry and workload activity. The README does not document the quorum model, the failure behaviour when a node is lost, or how a node is added to a cluster.

There is also an obvious trade-off in the design. Putting storage, networking, firewalling and virtualization under one interface means a single web service holds administrative authority over all of them, and the default admin credentials make that point acutely. The mitigation is present in the dependency list, with JWT, WebAuthn, PAM and TLS on port 8181, but the platform's centralisation is the fundamental shape of the risk, not a bug in it.

BSD 2-Clause and a dependency tree that carries its own upgrade cost

Sylve is licensed under the BSD 2-Clause License, with the LICENSE file in the repository as the authoritative text. This is a permissive licence with no copyleft obligations on derived work, which matters for a platform that is likely to be deployed on infrastructure you also sell. That is a licensing statement rather than legal advice.

The upgrade cost sits less in the licence than in the dependency tree. The Go module pins a long list of libraries, and a few of them are moving targets: a torrent library, a ZFS binding tracked at a pseudo version tied to a specific commit hash, and the libvirt client pinned to a commit dated 2025-11-17. Updating Sylve means pulling in whatever the project has moved to, and there is no compatibility promise in the README that would let an operator hold a dependency version steady.

The frontend side has its own toolchain, since the web/ directory is excluded from the Go module and the build runs a frontend target before the backend target. The Makefile also has cross-build-amd64 and cross-build-arm64 targets, and the repository includes a .air.toml file, which is the live reload configuration used by the Go air tool. Together with the CI workflow and a .gitmodules entry, this is a project with real development infrastructure behind it, even though the version numbers are still in the low range.

Contributions are handled through a contributor guide that the README asks you to read before submitting a pull request, and the project maintains a Discord and a documentation site at sylve.io/docs.

Editorial conclusion

Adopt Sylve if you run FreeBSD 15.0 or newer and want Bhyve, Jails, ZFS, PF and WireGuard administered from one browser instead of rc scripts and per-tool CLIs, and if you can commit to a rolling tip build for the newest code. Do not adopt it as a cross-platform virtualization console, since the backend is compiled with GOOS=freebsd and it manages FreeBSD specific facilities. Before installing, confirm the host has a configured system hostname, decide whether libvirt 12.5.0 or newer is needed for your use case, and change the default admin credentials right after the first login to https://<host>:8181.

Frequently asked questions

Official sources

1. AlchemillaHQ/Sylve on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases