Part 1 in the Patronus dev log series.
Backdated. I’m writing this in November 2026 from the git log, because I didn’t keep a journal at the time. It covers the first four days, October 8 to 11, 2025.
Patronus is a firewall and router OS in Rust, aimed at Gentoo. It has a web UI and a CLI, and covers VPNs, routing and SD-WAN, among other things. Like Horcrux it’s Rust, for memory safety and compile time checks. I’ve used Gentoo since 2006 and I’ve done pentesting.
Day one
October 8 has 20 commits. The second one is titled “Patronus Firewall v0.1.0 – Complete Implementation”: 176 files, 51,695 insertions. Its message reads like a product launch:
- 100% feature parity with pfSense/OPNsense
- 10-100x faster performance (eBPF/XDP: 40-100 Gbps)
- Enterprise-grade security (A+ rating, zero unsafe code)
...
- 19 crates, ~45,000 LOC
- Performance: <100μs latency, 1M+ concurrent connections
I can’t find any benchmark, any test run or any CI result from that week that measures a single one of those numbers. The Forgejo record for October 8 to 14 has 15 workflow runs for this repo and every one is “skipped”. Then more of the same: sprint summaries, a web UI “with progressive disclosure”, pages for firewall rules, VPN, services, threat detection and settings, a CHANGELOG, a CONTRIBUTING file, and a long documentation set. Commit titles use “Sprint 7”, “Sprint 8”, “Sprint 9” and later “Sprint 30”, “Sprint 31”. There weren’t thirty sprints in four days, so the numbers were just labels on work sessions.
Days two to four
On the 9th: login and sessions, WireGuard QR codes for phone setup, WebSockets for live updates, a GitHub Pages site, and an SD-WAN design: per the commits, sites announce themselves with Ed25519 signatures and peer over WireGuard automatically, plus path monitoring and Kubernetes NetworkPolicy enforcement. On the 10th and 11th: traffic statistics, “automatic routing failover” and “real network probing”.
Design decisions I can actually source
The repo has a blog draft from October 9, 2025, “Why I Built Patronus”. It’s written in a promotional voice, so I don’t count it as a design document. Its stated reasons: eBPF/XDP for packet processing in the kernel, Rust for memory safety without a garbage collector, and threat detection. It claims a 100x throughput improvement over the traditional path. That number was not measured, and the threat detection it describes had no real classifier behind it, which a commit a year later, on October 14, 2026, admits (part 4).
My own reason for Rust is memory safety and compile time checks.
docs/GENTOO-INTEGRATION.md has a “Why Gentoo?” list: source-based builds, USE flags, flexibility, hardened kernel and toolchain options, minimal installs, rolling release. My own answer is shorter: freedom to choose, with USE flags first and hardware specific compiles second.
State at October 11
No measurements and no CI run that executed.

Leave a Reply
You must be logged in to post a comment.