Does pfSense Need a Container-Based Build Environment for Repeatable Development?

pfSense's documented build path runs through pfSense-Tools on a FreeBSD host, producing installable ISO and memstick images from source. Repeatability hinges on matching the host FreeBSD release to the pfSense branch being built — for the current CE 2.7.x line the docs point at a specific FreeBSD 14.x release, though the exact pairing should be confirmed against the pfSense-Tools README before planning.

That requirement creates friction for developers who don't run FreeBSD daily. The pfSense-CE repository has included a Vagrantfile for provisioning a build VM, but whether it still tracks recent FreeBSD 13/14 baselines needs verification against recent commits. Container-based environments (Docker or Podman) are the usual route to reproducible toolchains on Linux and macOS hosts, yet it remains open whether FreeBSD's build toolchain, ports handling, and image-assembly steps run reliably inside a Linux container, or whether a VM is the only dependable isolation boundary.

The open decision

• Is the Vagrantfile still a valid starting point for a current pfSense CE build, or effectively unmaintained?
• Has a containerized pfSense build been demonstrated, or do FreeBSD-specific tooling dependencies rule it out?
• Would the project accept a container-based build path upstream, or is a pinned FreeBSD VM the intended long-term answer?