A firewall that sees it first
ModSecurity sits in front of WordPress and filters the common attacks before your site is asked to deal with them. On by default, set per domain, and yours to switch off if a rule ever fights your site.
Managed WordPress Hosting built different 馃挭
ModSecurity filters common attacks before the request reaches WordPress, cpGuard watches for the files that should not be there, and your site runs in a container of its own.
At a glance
ModSecurity sits in front of WordPress and filters the common attacks before your site is asked to deal with them. On by default, set per domain, and yours to switch off if a rule ever fights your site.
cpGuard scans for the files that have no business being on your site. A firewall is about the request and a scanner is about what got through, and a serious answer needs both of them.
One WordPress site per container, with its own files, memory, CPU and database. On shared hosting a compromised site next door shares your account. Here it does not share your container.
ModSecurity inspects requests before they reach WordPress and drops the ones matching known attack patterns, which is most of the automated traffic any WordPress site gets. It runs on the server in front of your site rather than inside it as a plugin.
That is your call, and plenty of people run one as well. The firewall is doing a different job from a plugin: it sees the request before WordPress is loaded, and a plugin sees it afterwards. Neither replaces the other.
Not yet. The firewall and the scanner run on the server and give us no per-site count we could show you honestly, so we show nothing rather than a made-up number.
The rest of what people switch for. The whole list is on the features page.
Firewall, isolation, HTTPS and backups on every Pressy.