Imunify360 vs Patchman for shared hosting security

The two products sit in adjacent corners of the shared-hosting security problem and they overlap less than the marketing implies. Imunify360 is a WAF, malware scanner, and brute-force protection layer for the whole server. Patchman patches vulnerable CMS files in place on customer accounts and sends them an email about it. Most hosts run one; a meaningful minority run both, which TuxCare itself acknowledges with an official integration page for Patchman.

This compares them on what they do, what they don't, and where the overlap actually is.

At a glance

Imunify360: defence in depth at the perimeter

Imunify360 is what you buy when the shared-hosting threat model is "someone is going to try". It catches the attack on the way in, before anything is written to disk. The WAF blocks SQLi and XSS attempts using the Comodo ruleset, the brute-force protection greylists IPs that are hammering wp-login.php or dovecot, and the malware scanner flags files that did slip through.

Its strength is that it is server-wide and operator-controlled. One subscription covers every account on the box, the admin tunes the rules centrally (see tuning the Imunify360 WAF), and customers don't have to do anything. Its weakness is that it does not fix vulnerable code — it just tries to stop the exploit. If a customer leaves WordPress 5.8 with a known RCE running, Imunify's WAF will block known exploit patterns, but the underlying vulnerability stays.

That's where virtual patching helps: Imunify ships ModSecurity rules that intercept known CVE-specific exploit patterns. It's not file-level — it's WAF-level — and it works until the next variant of the exploit emerges that the rules don't match.

Patchman: fix the actual files

Patchman's pitch is the opposite. Instead of blocking exploit traffic, it scans customer accounts for outdated WordPress, Joomla, Drupal, and a curated list of plugins, then edits the vulnerable files in place to apply backported security patches. The customer gets an email saying "we patched your WordPress against CVE-2024-XXXX — log in to verify". The site stays on the same version it was on; only the vulnerable lines change.

For a shared host running 10,000 accounts where customers ignore update prompts for years, this is the only thing that actually moves the needle on the long tail of WordPress vulnerabilities. The WAF in front doesn't matter when the customer's plugin has a 5-year-old auth bypass — Patchman closes that hole directly.

The catch: coverage is finite. Patchman patches what its team builds patches for. Niche plugins, custom themes, and forks are not covered. And it's a per-domain product, which scales differently from Imunify's per-server pricing.

Where they overlap (and don't)

• Malware detection: both scan. Imunify's scanner is broader and tied into its WAF event stream. Patchman's is narrower — it cares about the specific files it knows how to patch. If you run both, Imunify is the primary scanner.
• CVE coverage: Imunify covers via WAF rules; Patchman covers via file patching. Different mechanisms for the same outcome — neither replaces the other for full coverage.
• Notifications: Imunify is operator-facing. Patchman emails customers directly, which doubles as a marketing channel ("look, we patched your site for you").

The places they don't overlap at all: WAF (Imunify only), brute-force protection (Imunify only), file-level CMS patching (Patchman only), per-user emails (Patchman only).

Decision matrix

Use Imunify360 alone when:

• Your fleet is mostly business or technical customers who keep their own CMS updated.
• You want one product covering WAF, scanning, and brute-force.
• You sell on "secure shared hosting" generically without per-customer touchpoints.
• You want CloudLinux + Imunify360 + KernelCare as the standard TuxCare stack.

Use Patchman alone when:

• You only need CMS hardening, not a WAF (e.g. there's already a CDN-level WAF upstream).
• Customer-facing patch notifications are a feature you want to charge for.
• Per-domain pricing fits your model better than per-server.

Run both when:

• You run cheap, high-volume shared hosting with non-technical customers who never update.
• Audit framework requires both perimeter (WAF) and at-rest (file patching) controls.
• The per-customer patch notification is a retention lever — Patchman emails effectively say "look how much we do for you" once a month.

TuxCare publishes an official Imunify360-Patchman compatibility note specifically because hosts run both. There is no conflict — Imunify's malware scanner ignores files patched by Patchman, and Patchman's file edits don't trigger Imunify's "modified file" alerts when configured correctly.

Cost considerations

The pricing models point at different fleet shapes.

• Imunify360 is per-server, flat above a minimum. A box with 500 accounts costs the same as a box with 50. Unit economics improve as you densify.
• Patchman is per-domain. Cost scales linearly with the number of customer domains, regardless of density.

For a host with many low-traffic accounts on a single box, Imunify is the cheaper-per-account choice. For a host with fewer, higher-value accounts and a focus on per-domain features, Patchman's model can come out ahead. Tier breakdowns for both — and combined-stack discounts — are on the pricing page and the Imunify360 license page.

What we recommend

For most shared-hosting operators on cPanel, the baseline stack is CloudLinux + Imunify360 + KernelCare. That covers the perimeter, the kernel, and the per-account isolation. Add Patchman when the customer base skews non-technical and you want to point at a tangible "we did this for you" deliverable in the monthly invoice email.

Don't add Patchman as a substitute for Imunify360. The WAF and brute-force layers do most of the daily blocking work — Patchman is a complement, not a replacement.

Next steps

• Install the base layer: install Imunify360 on cPanel.
• Stop false positives once it's deployed: tune the Imunify360 WAF.
• Buy a seat or get volume pricing: Imunify360 license.