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 memory, its own CPU and its own database. On shared hosting the site next door being compromised is your problem too. Here it isn't.
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.
No at this time. This is totally a feature we would like to deploy, but it's not yet available.
The rest of what people switch for. The whole list is on the features page.
Firewall, isolation, HTTPS and backups on every paid Pressy.