This isn't a product born from spotting a market. It solved a real operations problem first, and became a product afterward.
On a Linux server hosting 22 production websites, a routine look at the access log showed not visitors but bots: wave after wave of /wp-login.php, /.env, /phpMyAdmin, path traversal, scanner signatures — hundreds of hits a day, from everywhere.
The first response was the same as everyone's: spot a suspicious IP, add a firewall rule by hand. That lasted a few weeks before it became obvious — the other side is automated and you are manual. You cannot win that fight.
fail2ban and friends are powerful, but the rules are hard to write and maintain — one regex change away from banning real users. And with no evidence retained, "why was this IP blocked?" has no answer later.
They require handing your traffic or logs to a third party, and moving your DNS. For people who self-host, shipping logs off the box is exactly the thing they don't want.
Most people's status quo — until the day scanning turns into intrusion, and the log turns out to have been full of warnings all along.
Everything in this category reads logs, decides, and writes a firewall rule. The difference is not what it can read, it is how much work is left to you afterwards:
| Apache | nginx | SSH | FTP | NAS web | NAS SSH | |
|---|---|---|---|---|---|---|
| SvrGuard | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| fail2ban | ✅ | ✅ | ✅ | ✅ | ❓ | ❓ |
| Cloud WAF / managed | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
"NAS web" is the Web Station / reverse-proxy access log; "NAS SSH" is failed SSH logins on the NAS, which the package points at /var/log/auth.log during install. DSM's own Auto Block already covers failed SSH logins, but failed logins are all it counts: scanning for /.env or /wp-login.php carries no login, so it never sees it — that is the half we add.
On FTP, we read the PAM authentication failure line, which most FTP servers emit; fail2ban also ships rules for each server's native format; it is not a native DSM package and we have not verified whether it works there, so those cells are ❓ rather than ❌. Overall it reads as many sources as we do and more (mail, databases) — its cost sits elsewhere: you maintain the regexes and thresholds, verdicts leave no evidence behind, and several machines have nowhere central to be seen. A cloud WAF blocks more, in exchange for your traffic and logs leaving the building.
The requirement was simple: read the logs on my machine, decide on my machine, write to my machine's firewall — automatically, with evidence, and without bothering me.
SvrGuard is that requirement, shipped: a single binary, 15 built-in rules, native nftables / ipset control, events and evidence in a local SQLite database. Once installed, that server blocked 721 attacking IPs from 48 countries in its first 9 days, with zero manual intervention.
It stood guard over those 22 production sites before it ever appeared on this website. It was a tool in daily use long before it was a product — every feature exists because it was genuinely needed.
