Softaculous auto-upgrades and backups for hosting fleets

An out-of-date WordPress core is the single most common reason a shared-hosting account gets compromised, and every compromised account is a support ticket, a reputation hit, and often an IP on a blocklist. Softaculous can close that gap automatically: it checks for new versions once a day, upgrades the installs that opted in, and takes a backup first so a failed upgrade rolls itself back. The catch is that the defaults leave most of this off, and the backup side quietly eats disk if you don't scope it.

This is the host's-eye view — what to set at the admin level so the whole server benefits, where the end-user toggles live, and how to keep automated backups from filling /home. It assumes Softaculous is already installed and licensed; if not, start with installing Softaculous on cPanel.

How the auto-upgrade cron works

Softaculous drops a cron that runs roughly every 24 hours. On each run it compares every tracked installation against the latest version in its catalogue, and for any install where auto-upgrade is enabled and server load is low enough, it upgrades in place. That's the whole mechanism — there's no daemon, no webhook, just a daily sweep.

Two gates decide whether a given install actually upgrades:

• The per-install auto-upgrade setting, chosen by the end user (or by your default) on the Edit Installation page.
• A server-load threshold. Softaculous only upgrades when the normalised load (load average divided by core count) is below a threshold — 0.70 by default. On a busy box past that line, upgrades are skipped for that run and retried the next day. This stops an upgrade storm from tanking a server, but it also means a permanently loaded server can fall behind on patches. Raise the threshold in the admin settings if your fleet runs hot but you still want timely upgrades.

Set the admin defaults first

Everything below lives in the Softaculous Admin Panel → Settings (WHM → Plugins → Softaculous, then the Settings cog), and it governs every account on the server. Get these right once instead of per user.

Default auto-upgrade behaviour for new installs

Under Settings → Auto Upgrade you control what new installations default to. The useful options:

• Auto Upgrade — off, upgrade to the latest minor version, or upgrade to the latest major version. Minor-only is the sane default for a mixed fleet: security and point releases land automatically, major version jumps (which break themes and plugins) stay manual.
• Auto Upgrade WordPress Plugins and Auto Upgrade WordPress Themes — separate toggles. Plugins are where most WordPress vulnerabilities actually live, so enabling plugin auto-upgrades usually buys more security than core upgrades alone.

Kill or force upgrades globally

Two blunt instruments for when you need them:

• Disable Auto Upgrade — a master switch. When on, no installation auto-upgrades regardless of what the end user chose. Use it to freeze the fleet during an incident or a suspected bad upstream release.
• Per-script disable — turn off auto-upgrade for one script (say, a plugin family that keeps shipping broken releases) without touching the rest.

There's no honest "force every user's site to upgrade" button that overrides individual installs cleanly — the model is opt-in per install with your chosen default. If you want patched-by-default, set an aggressive default before your customers start installing, because changing the default later doesn't retroactively flip existing installs.

Backups: the part that saves you at 2am

Softaculous does two distinct kinds of backup. Don't conflate them.

Pre-upgrade backups (automatic, transient)

Before every auto-upgrade, Softaculous takes a backup of that install. If the upgrade fails, it restores that backup automatically — the site is left exactly as it was. This is the safety net that makes unattended upgrades tolerable.

The cost is disk and I/O: every upgrade writes a full archive under the user's account first. On a server with thousands of installs upgrading on the same daily run, that's real pressure on /home. If you're already backing accounts up with JetBackup or another system, the pre-upgrade backup is belt-and-braces, and you can turn it off to reclaim the space:

In the admin settings, enable Disable Backups before Auto Upgrade. End users see the same option in their Softaculous panel under Edit Settings.

Automated scheduled backups (recurring, retained)

Separately, each install can be put on a backup schedule from the Edit Installation page. This is a genuine rolling backup, not just an upgrade safety net:

• Frequency — Don't Backup, Once a Day, Once a Week, Once a Month, or a Custom cron expression (min/hour/day/month/weekday) for anything else.
• Backup Rotation — the maximum number of backups to keep for that install. When the limit is hit, Softaculous deletes the oldest. This is your disk governor — set it against the space you can afford, because these archives live in the account by default.
• Backup Location — where the archive goes.

Push backups off the server

Local backups don't survive the disk they sit on. Add remote backup locations at the admin level so your customers' scheduled backups land somewhere else. Under Admin Panel → Backup Locations, Softaculous supports FTP, SFTP, Amazon S3 (and S3-compatible stores like Wasabi and Backblaze B2), Dropbox, Google Drive, OneDrive, and WebDAV. Once a location exists, it appears in the Backup Location dropdown on every Edit Installation page.

For a hosting fleet, an S3-compatible bucket is the pragmatic choice — cheap, off-box, and it keeps /home clear. Point it at the same object store you use for Plesk or cPanel account backups so you're managing one destination, not five.

Rolling back a bad upgrade

Auto-rollback only covers failed upgrades. When an upgrade succeeds technically but breaks the site — a theme that no longer renders, a plugin conflict — you roll back manually, and that only works if a backup of the earlier version exists.

From the Softaculous Backups page, restore the archive taken before the upgrade. This is exactly why the scheduled-backup rotation matters: keep at least a couple of versions' worth of history so "restore to last week" is always available. If you kept only the single pre-upgrade backup and it's already been overwritten by the next run, there's nothing to roll back to.

Where this fits in a security stack

Auto-upgrades cut the volume of compromises; they don't make a server bulletproof. A zero-day in an unpatched plugin still lands before the daily cron runs, and Softaculous only manages installs it created or imported — hand-installed WordPress sitting in a subdirectory is invisible to it. Pair automated updates with server-side malware scanning and remediation via Imunify360's cleanup workflow so the sites Softaculous can't reach, and the ones it patches a few hours too late, still get caught.

Next steps

• Set up Softaculous WordPress staging — test major upgrades before they hit production
• Import existing installations into Softaculous so hand-built sites get auto-upgrade coverage
• Softaculous vs Installatron — and activate a Softaculous license if you're provisioning a new node