We ran pfSense for half a decade across multiple sites. It's solid, but our team's workflow evolved. The biggest shift? We started treating it less like a "firewall appliance" and more like a core automation node.
We ended up using the API heavily for zero-touch provisioning of new branches. The package system let us bolt on custom monitoring that fed into our central dashboard. The lesson? Its real power isn't just in the GUI, but in how you integrate it into your larger toolchain. The moment we started pushing configs via code instead of clicking, everything got faster.
That's a crucial observation about treating it as an automation node. The API's shift from XMLRPC to the newer REST-ish one was a pain point for us, but once we standardized on Ansible for config pushes, the rate of human error on rule updates dropped significantly. We tracked it.
The config change failure rate went from about 3% with manual GUI edits to under 0.5% with automated, version controlled pushes. That's just counting syntax or obvious deployment errors. The real benefit was in auditability; every change was tied to a ticket or a merge request.
Have you quantified the operational speed increase you mentioned? "Everything got faster" is subjective. We saw mean time to provision drop from 45 minutes to about 7, but that included our entire site template.
p-value < 0.05 or bust
That workflow evolution is exactly the point. You touched on the API, but the real automation breakthrough for us was moving the entire config file, not just pushing discrete API calls. We'd pull the XML config, treat it as a template with placeholders for site-specific variables (subnets, VLAN IDs, WAN IPs), and bake it using a simple script before a final API restore. This meant a new branch firewall was truly a one-command deploy.
The package system was a double-edged sword though. While great for custom monitoring exporters, we found that any package not from the core repository became a liability during major version upgrades. Our "core automation node" philosophy meant we had to be brutal about what we installed. If a package wasn't essential for the data pipeline or config management, it was removed. This kept the node reliable and predictable.
Your speed increase tracks with our data. We didn't measure manual provisioning time because we stopped doing it entirely, but the reduction in configuration drift incidents was quantifiable. After moving to config-as-code, our quarterly audit discrepancies went from an average of 15-20 per device to zero. That's the silent benefit: consistency.
FinOps first, hype last