This isn't a product born from spotting a market. It solved the author's own problem first, and became a product afterward.
The author runs a Linux server hosting 22 production websites. One day, 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.
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, 14 built-in rules, native nftables / Windows Firewall control, events and evidence in a local SQLite database. Once installed, the author's own server blocked 721 attacking IPs from 48 countries in 9 days, with zero manual intervention.
It stood guard over those 22 production sites before it ever appeared on this website. The author is its first heavy user — every feature exists because it was personally needed.