Install Imunify360 on Plesk — what's different from cPanel

Imunify360 runs on Plesk with the same agent and the same cloud-side intelligence as the cPanel build, but the integration story is meaningfully different. Plesk owns more of the stack — its own ModSecurity wrapper, its own Fail2Ban orchestration, its own extension sandbox — and Imunify has to slot in around all of that without doubling up on bans or fighting the WAF for control of the same rules.

This guide covers the install on a Plesk Obsidian server (AlmaLinux 8/9 or Ubuntu 22.04 — the two combinations TuxCare actively tests), the license activation flow through the extension UI, and the four post-install settings that catch every Plesk admin off guard because the cPanel docs don't mention them. Budget 25 minutes end-to-end on a 4 GB VPS.

Before you start

• Plesk Obsidian 18.0.50 or newer, with root SSH.
• A supported OS: AlmaLinux 8 or 9, Rocky 8 or 9, Ubuntu 20.04 or 22.04, or Debian 11/12. CentOS 7 is end-of-life and no longer supported by Imunify360 as of agent 6.13.
• 1 GB of free RAM beyond Plesk's footprint. The agent and the scanner together sit around 500-800 MB resident on a busy node.
• An Imunify360 license key. New buyers can grab one on the Imunify360 license page.
• Port 443 outbound to *.imunify360.com open. The agent pulls reputation feeds, signature updates, and the cloud-side WAF rule deltas every five minutes.
• Plesk's ModSecurity component installed (Tools & Settings → Web Application Firewall). Imunify360 will replace the active ruleset but it still uses Plesk's ModSec binary.

Install via the Plesk extension

The supported path on Plesk is the extension, not the standalone deploy script. The extension wraps the install, registers the license, configures the Plesk UI integration, and sets up the Plesk Action Log handlers. The shell installer is available for air-gapped or scripted deployments but you lose the in-Plesk UI hooks.

# Log into Plesk → Extensions → Extensions Catalog → search "Imunify360"
# Click Install. Plesk pulls the agent, runs i360deploy.sh under the hood,
# and registers a service handler in /etc/init.d.

When the install finishes you'll see a new Imunify360 item in the Plesk sidebar. Activate the license from there: paste the key, the agent calls home, and within 60 seconds the dashboard shows the threat feed, the malware scanner status, and the WAF rule version.

If you prefer the CLI path:

wget https://repo.imunify360.cloudlinux.com/defence360/i360deploy.sh
bash i360deploy.sh --key=YOUR-LICENSE-KEY
plesk installer add --components imunify360

The trailing plesk installer call registers the agent with Plesk so the panel sees it as a managed component. Without that step Plesk's update routines will fight Imunify on the next panel upgrade.

What Imunify takes over on Plesk

After install, Imunify360 owns:

• The ModSecurity rule set. Plesk's Tools & Settings → Web Application Firewall page switches to showing "Imunify360" as the active set. The OWASP, Atomic, and Comodo pre-configured options are greyed out — Plesk knows not to load them.
• Malware scanning. The Plesk built-in scanner (which is a thin wrapper over ClamAV) keeps running unless you turn it off under Tools & Settings → Antivirus. Two scanners doubling-scan every upload eats IO on busy servers — turn the Plesk one off.
• Brute-force protection on auth surfaces. Imunify's WebShield handles HTTP-level brute-force; the Plesk login page, WordPress wp-login, Joomla admin, etc. all flow through it once the extension is active.

What Imunify does not take over:

• Plesk Fail2Ban, which is doing its own thing on Postfix, Dovecot, SSH, and the Plesk panel auth log. See the next section.
• SSL/TLS configuration. Imunify is layer-7 detection, not termination. Plesk keeps managing Let's Encrypt and the SSL It! extension.
• The Plesk firewall extension, which still configures iptables/nftables underneath.

The Fail2Ban overlap — the one thing every Plesk admin gets wrong

This is the single most common Plesk + Imunify360 issue on the Plesk community forum: a real user fails their Plesk password three times, Plesk Fail2Ban bans the IP at the iptables layer, and Imunify's WebShield also tracks the failure. The admin unblocks the IP in Imunify, the user still can't connect because Fail2Ban's rule is still there, and now there are two unblock paths to remember.

The fix is to scope each tool to its own surface:

# Disable Fail2Ban's plesk-* jails, let Imunify handle HTTP auth
plesk bin ip_ban --disable-jail plesk-panel
plesk bin ip_ban --disable-jail plesk-postfix
plesk bin ip_ban --disable-jail plesk-roundcube

# Keep Fail2Ban for the surfaces Imunify doesn't see
# plesk-dovecot, plesk-proftpd, ssh — leave enabled

Imunify now owns Plesk panel auth, mail submission, and Roundcube. Fail2Ban keeps SSH, IMAP/ POP3, and FTP. Single unblock path per surface, no double-bans.

CloudLinux on Plesk — what you actually get

CloudLinux integrates with Plesk but not at the same depth as cPanel. CageFS, LVE per-user limits, and the PHP Selector all work, but the Plesk UI surfaces them through CloudLinux's own extension rather than native panel pages. Imunify360 features that depend on CloudLinux — PHP Immunity / Proactive Defense, MySQL access rules, full per-user file integrity tracking — work on Plesk + CloudLinux but not on Plesk on bare AlmaLinux.

If you're running Plesk on AlmaLinux without CloudLinux, you still get the WAF, malware scanner, WebShield, and Inbox security — about 80% of the Imunify360 value. The remaining 20% is the CloudLinux-dependent sandboxing.

Imunify Email Security — Postfix, not Exim

Plesk runs Postfix for outbound mail; cPanel runs Exim. The Imunify Email Security setup on cPanel does not translate. On Plesk you install Imunify Email separately via the same extension catalog. It hooks into Postfix's smtpd_milters and non_smtpd_milters rather than Exim's content-scanning ACL.

The license is bundled with Imunify360 6+, so no extra key is required, but the agent has to be told to enable email scanning explicitly:

imunify360-agent features enable imunify-email
systemctl restart postfix

Verifying the install

Three quick checks after install:

# Agent reports healthy and licensed
imunify360-agent version
imunify360-agent register --status

# ModSecurity is running Imunify's rule set, not Plesk's
plesk bin server_pref --show-web-app-firewall
# expected: rule_set: imunify360

# WebShield is intercepting HTTP
curl -sI -A "BadBot" https://yourpanel.example.com/ | head -3
# expected: 403 if WebShield is graylisting unknown agents

If register --status returns "unregistered" but the extension shows the key as accepted, the cloud handshake failed — almost always a firewall rule blocking outbound 443 to *.imunify360.com. Allow it and run imunify360-agent register YOUR-KEY manually.

What's still missing on Plesk vs cPanel

Honest list of feature deltas as of agent 6.14:

• No per-reseller view. cPanel's reseller-scoped Imunify dashboard isn't replicated on Plesk because Plesk's reseller model is different. Resellers see their own subscriptions via the Plesk service plan, not via Imunify.
• No "one-click backup restore" hook. On cPanel, Imunify can hand off an infected site to JetBackup or cPanel's built-in restore. The Plesk equivalent (Plesk Backup Manager) is not yet wired in, though TuxCare's roadmap has it for 6.15.
• Less aggressive CageFS defaults. Even with CloudLinux, the per-user hardening is shallower because Plesk subscriptions don't map cleanly to CloudLinux LVE IDs without manual configuration.

None of these are dealbreakers — they're rough edges. For the core security stack (WAF, scanner, brute-force, Proactive Defense) the Plesk experience is on parity with cPanel.

Next steps

• For the WAF tuning settings that prevent the first wave of false positives, see tuning Imunify360 WAF false positives.
• If you're running Plesk behind Cloudflare, the WebShield real-IP guide applies identically — same agent, same config file path.
• For the licensing detail and per-account pricing, the Imunify360 license page covers the single-server, multi-server, and per-user tiers.