Upgrade a Check Point Gateway with CPUSE, Step by Step

Before you run this

CPUSE (the Gaia Deployment Agent) is Check Point's built-in tool for importing, verifying, and installing hotfixes and major-version upgrades on a Gaia gateway. In this guide I use it to take one gateway from one major version to the next. A major-version install reboots the box and replaces the running OS image — while it runs, that gateway passes no traffic and its management is offline. Treat it as a full outage, not a quick patch.

You need administrative access to Gaia — the admin user in the Gaia Portal (WebUI) or in clish, and expert-mode (root) for a couple of verification commands. There is no "test" mode that changes nothing; verifying a package is read-only, but installing is not.

Do this in a maintenance window, and:

Keep an out-of-band console open — the appliance serial/LOM console, not SSH. A major upgrade drops SSH and the WebUI for several minutes, and if it goes wrong the console is your only way in.
Back up the configuration and take a Gaia snapshot before you touch anything. A snapshot is your real rollback. CPUSE can create one automatically for a major upgrade, but take your own so you know exactly what you have.
If this is a cluster, upgrade one member at a time and confirm the standby is healthy before starting the second. Never upgrade both at once.
Read Check Point sk92449 (CPUSE) and the release notes / upgrade guide for your target version before you begin — verify the exact package name and any prerequisites for your hardware.

Assumptions for this guide: a single Gaia appliance gateway running R81.10, being upgraded to R81.20, managed by a separate Security Management Server (this is not a standalone/all-in-one). No VSX. The Deployment Agent is already recent — CPUSE updates itself, but confirm in the Portal. If your versions differ, the procedure is the same; only the package name changes.

Step 1 — Back up and snapshot

Take a Gaia snapshot from the Portal so you have a named, revertible image before the upgrade.

Gaia Portal → Maintenance → Snapshot Management.
New → give it an obvious name like pre-R81.20-upgrade and a description, then create it. On an appliance this can take a while and needs free disk; let it finish.

Also export a configuration backup (Maintenance → System Backup, or add backup in clish) and copy it off-box. The snapshot restores the whole OS; the config backup is a lighter safety net.

If you prefer the CLI, snapshot creation in clish is:

add snapshot pre-R81_20-upgrade description "before R81.20 upgrade"
show snapshots

Step 2 — Confirm your current state

Know exactly where you're starting from. In clish:

show version all          # Gaia / product version
show installer status      # CPUSE / Deployment Agent status

In expert mode, to see installed products and hotfixes:

cpinfo -y all

Write down the current version and installed hotfixes. If the gateway is behind on hotfixes for its current train, decide whether to sort that first — check the target version's upgrade guide for prerequisites.

Step 3 — Get the target package into CPUSE

There are two normal ways to make the R81.20 upgrade package available: let CPUSE download it from Check Point's cloud (the box needs outbound internet or a configured proxy), or import a package you downloaded from the Check Point support site.

The Gaia Portal way (mainstream)

Gaia Portal → Upgrades (CPUSE) → Status and Actions.
The list shows available packages under categories such as Hotfixes and Major Versions. Find the R81.20 major-version upgrade package for your appliance.
If it shows as available online, select it and choose Download. If you already downloaded the .tgz from Check Point, use Import Package and point it at the file.
Wait until the package state shows it is imported/ready before continuing. Don't rush the next step while a download is still running.

The clish way

Confirm the exact keywords against sk92449 for your build — the installer command family is what you want. The common form is:

show installer packages all        # list what CPUSE can see
installer download <number>         # pull the package from Check Point cloud

or, for a package you copied onto the box:

installer import local /var/log/upload/Check_Point_R81.20_<...>.tgz
show installer packages imported    # confirm it's imported, note its number

Use the real filename from Check Point in place of the placeholder. If you're unsure of the exact installer sub-command or the package number, list packages first and read them off the output rather than guessing.

Step 4 — Verify the package (read-only)

Before installing, run CPUSE's verifier. This checks compatibility, disk space, and prerequisites without changing anything — always do it, and always read the result.

In the Portal, select the imported R81.20 package and choose Verifier (verify). In clish:

installer verify <number>

If verification reports a problem — insufficient disk, a missing prerequisite hotfix, an unsupported path — stop and resolve it. A failed verify is CPUSE telling you the install would fail or leave the box in a bad state.

Step 5 — Install

Only proceed once verify is clean, your snapshot exists, and you're on the console.

Gaia Portal → Upgrades (CPUSE) → select the R81.20 package → Install.
When prompted about creating an automatic snapshot for a major upgrade, allow it — that's a second safety net on top of yours.
Confirm. The gateway will reboot. The Portal and SSH will drop. Watch progress on the console.

CLI equivalent:

installer install <number>

Do not touch the box, cut power, or start pulling cables during the install. Let it reboot and settle.

Step 6 — Verify the upgrade

When the gateway comes back, log in via console first, then confirm the version.

In clish:

show version all
show installer status

In expert mode:

fw ver              # firewall version
cpinfo -y all       # products and hotfixes now installed

Then confirm the security stack is actually up:

cpstat os -f all    # system status
fw stat             # policy loaded / interfaces enforcing
cphaprob stat       # cluster state — if this is a cluster member

Finally, on the management side: open SmartConsole, edit the gateway object, and set its version to R81.20 (adjust the object to match the installed version), then install policy. A newly upgraded gateway often needs its object version updated and policy reinstalled before it enforces correctly. Confirm real traffic is passing before you close the window.

For a cluster, verify the upgraded member joins as expected and takes over cleanly before upgrading the next one.

Rolling back

If the upgrade fails or the gateway misbehaves, your rollback is the Gaia snapshot you took in Step 1:

Gaia Portal → Maintenance → Snapshot Management → select pre-R81.20-upgrade → Revert. The box reboots into the previous image.

The exact clish revert command has moved between versions — confirm it in the Gaia Administration Guide for your version and in sk92449 rather than guessing. The Portal revert is the safe, standard path and is what I'd use under pressure.

After a revert, re-check the version with show version all, confirm policy is loaded (fw stat), and make sure the gateway object in SmartConsole matches the version it's actually running again. Then work out what verification was trying to warn you about before you attempt the upgrade a second time.