# Imunify360 Force Update and Rollback: Safe Staged Rollouts

Source: https://srvscripts.com/guides/imunify360-force-update-rollback/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

Imunify360 releases a new version roughly every few weeks, and 2026 has brought a steady stream of features such as the Layer 7 rate limiter, Under Attack Mode for WebShield and the WordPress WAF being enabled by default. Yet a server often shows an older version for days after the announcement, and the update button in the WHM plugin does nothing.

In short: Imunify360 updates arrive through the staged rollout automatically, usually within two weeks of release, via the agent’s own update cron.

That is the staged rollout working as intended: new builds are released to a growing percentage of servers over about two weeks so that a regression affects a small fraction of the fleet first. This guide explains how to live with that schedule, jump ahead of it when a fix is urgent, and step back when a release causes trouble.

**Short answer:** Imunify360 updates arrive through the staged rollout automatically, usually within two weeks of release, via the agent’s own update cron. To update immediately run `dnf update imunify360-firewall` on EL systems or `apt-get install --only-upgrade imunify360-firewall` on Debian and Ubuntu; if the repository still offers the old build, run the official force script `imunify-force-update.sh` from the Imunify repository. To roll back, install a specific earlier package version with `dnf downgrade` or `apt-get install imunify360-firewall=<version>` and pin it until the next release.

## How the staged rollout works

The Imunify repository serves different package versions to different servers based on a rollout percentage that CloudLinux increases over roughly fourteen days. `imunify360-agent version` shows what is installed; the changelog on the vendor site shows what is current. If the two differ, the server is simply not in the rollout cohort yet. The agent checks for updates on a schedule and applies them, so no action is needed unless a security fix or a bug you are hitting is in the newer build.

## Update manually

On AlmaLinux, CloudLinux and other EL systems:

```
imunify360-agent version
dnf clean all
dnf update imunify360-firewall -y
systemctl restart imunify360
imunify360-agent version
```

On Debian 12 and 13 and Ubuntu 22.04 and 24.04:

```
apt-get update
apt-get install --only-upgrade imunify360-firewall -y
systemctl restart imunify360
```

If the package manager reports nothing to update while a newer version exists, the repository metadata for this server is still on the earlier stage. Move to the force method below.

## Force the latest build

CloudLinux publishes a script that switches the server to the current release regardless of rollout cohort:

```
cd /root
wget -O imunify-force-update.sh https://repo.imunify360.cloudlinux.com/defence360/imunify-force-update.sh
bash imunify-force-update.sh
imunify360-agent version
```

The script refreshes the repository configuration, installs the newest packages and restarts the agent. It is safe to run repeatedly, and the same script serves ImunifyAV installations. For pre-release testing on a non-production box, the beta channel is available by enabling the testing repository for a single transaction: `dnf update imunify360-firewall --enablerepo=imunify360-testing`. Never enable that repository permanently on a customer-facing server.

## Roll back a problem release

Rollback is a package downgrade. List the versions the repository still carries and install the previous one:

```
dnf --showduplicates list imunify360-firewall
dnf downgrade imunify360-firewall- -y
systemctl restart imunify360
```

On Debian and Ubuntu, `apt-cache madison imunify360-firewall` lists available versions and `apt-get install imunify360-firewall=<version>` installs one. Then stop the agent’s own updater from immediately reinstalling the newer build: on EL add `exclude=imunify360-firewall` to `/etc/dnf/dnf.conf` and on Debian use `apt-mark hold imunify360-firewall`. Remove the pin as soon as a fixed release is announced, and open a ticket with the vendor describing the regression so it is fixed rather than avoided. Rollback does not touch the database of blocked addresses or the WAF rules, which live separately and are versioned by the rule set update, not the package.

## Verify and keep it running

After any update or rollback confirm the agent is running and healthy:

```
imunify360-agent version
imunify360-agent rstatus
systemctl status imunify360 imunify360-webshield
imunify360-agent check-domains 2>/dev/null | head
```

`rstatus` confirms the licence and the connection to the vendor’s servers. In WHM, the Imunify360 plugin’s dashboard should show the version in the footer and no warning banner about the agent not running. If the plugin has disappeared from WHM after an update, see [Fix Imunify360 missing from the WHM interface](/guides/fix-imunify360-missing-from-whm/). The main pitfall is leaving a downgrade pin in place and forgetting it, so the server misses months of security updates; note the pin in your change log with a review date. A second pitfall is running the force script during a major OS upgrade, which should instead be handled with the post-upgrade procedure in [Recover Imunify360 after an in-place OS upgrade](/guides/imunify360-after-os-upgrade/).

## Imunify360 force update at a glance

**Official documentation:** [Imunify360 documentation](https://docs.imunify360.com/), [cPanel & WHM documentation](https://docs.cpanel.net/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [Whitelist IPs and countries in Imunify360 from the CLI](https://srvscripts.com/guides/imunify360-whitelist-ip-cli/) · [Imunify360 in 2026: WAF by default, L7 rate limiting and Under Attack Mode tuning](https://srvscripts.com/guides/imunify360-under-attack-mode-2026/) · [Hardening a shared cPanel server with CageFS, ModSecurity (OWASP CRS) and Imunify/ClamAV](https://srvscripts.com/guides/harden-shared-cpanel-server/).

## Frequently asked questions

### Does the force update script also update ImunifyAV and ImunifyAV+?

Yes. The same script detects which product is installed and updates it, so it works on servers running only the antivirus tier as well as full Imunify360.

### How long does an Imunify360 staged rollout take to reach every server?

Roughly two weeks from the release announcement, with the cohort growing in steps. Security fixes are sometimes accelerated, but if you need a specific fix today the force script is the reliable route.

### Can I undo a forced update if the new version causes problems?

Yes. Downgrade the package to the previous version with dnf or apt, hold or exclude it so the updater does not reapply the new build, and remove the hold once a corrected release ships.
