User guide
What Night Agent does, one step at a time
A detailed walkthrough of each upgrade type and the workflow around it — the same operational reference that ships inside the app. It describes what the portal does at every phase, and the warnings worth reading before you point it at a production firewall.
On this page
Jump to a topic
Upgrade types
Before you begin
Upgrade type
Single firewall upgrade
For standalone firewalls that are not part of an HA pair. Causes a single reboot outage.
Pre-flight checks Optional
Connects to the firewall and runs a set of pre-flight checks: NTP sync, no candidate config, valid licenses, no active jobs, no config locks, sufficient disk space for the target image, CPU utilization, clock sync, dynamic-updates status, and — critically — verifies the device is not in an HA pair. Results are shown per-check with pass/fail. You can proceed to upgrade even if some checks fail.
Configuration backup Auto
Downloads the full running configuration as
config_backup.xml via the PAN-OS XML API export
endpoint. Available for download from the status page immediately
after this step completes — before the upgrade touches anything.
Pre-upgrade snapshot Auto
Captures the operational state of the firewall: NICs, routing table,
ARP table, BGP peers, IPSec tunnels, session statistics, content
version, MTU, and more. Saved as pre_snapshot.json.
Content update Auto
Checks for available content updates, downloads the latest threat and antivirus signatures, installs them, and waits for the install job to complete with an OK result before proceeding.
Software download & install Auto
Downloads the target PAN-OS version from Palo Alto update servers (if
not already present), installs it, and reboots the device. If the API
session times out during this long operation (common on installs that
take 15–30 min), the recovery block kicks in: it waits for the
install job to appear, confirms SWInstall result: OK,
then sends the restart command. After reboot, it waits for the device
to be ready and verifies the target version is running.
⚠ The firewall is unreachable during reboot (~5–10 min).
Post-upgrade snapshot & comparison Auto
Captures the same operational state as the pre-snapshot and runs a side-by-side comparison. Results show what changed (route count, session stats, content version, and so on) and flag anything outside expected thresholds. Both snapshot files are available for download.
Upgrade type
HA pair upgrade (active/passive)
Upgrades both devices with two controlled failovers. Preemption must not be enabled. Traffic is briefly interrupted twice.
Pre-flight checks — both devices Optional
Runs the same pre-flight checks as a single firewall on both primary and secondary. The HA check is skipped for HA pairs (having HA enabled is expected). Results are shown in two side-by-side panels with per-check pass/fail.
Config backup & pre-snapshot (primary) Auto
Backs up the running config from the primary (both devices share the same config when HA is synchronised). Takes the pre-upgrade operational snapshot.
Content update (primary → syncs to peer) Auto
Downloads and installs the latest content on the primary with
sync-to-peer: yes. PAN-OS pushes the same content to the
secondary automatically — only one operation needed.
Disable preemption on primary + commit HA
Sets election-option > preemptive: no on the primary
and commits. The commit must succeed before the upgrade
proceeds — if it fails, the upgrade aborts. This prevents the
primary from automatically reclaiming active state the moment it comes
back online after its upgrade, which would cause a second failover
before state sync completes. The original setting is saved and
restored after both upgrades finish.
Download software to primary + sync to peer Auto
Downloads the target PAN-OS image to the primary with
sync-to-peer: yes. One download, both devices get the
image.
Suspend primary → verify secondary active HA
Issues request high-availability state suspend on the
primary. Polls show high-availability state on the
secondary until it reports active and the primary reports
suspended. Traffic now flows through the secondary.
⚠ First traffic interruption — brief failover.
Install & reboot primary Auto
Installs the target version on the primary and reboots it. Includes
the same session-timeout recovery as a single firewall: if the API
session expires mid-install, the recovery logic detects the
SWInstall: OK job and sends the restart command. Waits
for show chassis-ready: yes.
Verify primary passive + state sync complete HA
Polls show high-availability state until the primary is
passive and state-sync: Complete. Only then
does the upgrade proceed — no partial state upgrades.
Manual pause for verification Optional
If Wait between upgrades is set to more than 0 minutes on the form, the upgrade pauses here before touching the secondary. Use this window to verify traffic is flowing correctly on the newly-upgraded primary.
Suspend secondary → verify primary active HA
Suspends the secondary. Polls until the primary is active
and the secondary is suspended. Traffic now flows through
the upgraded primary.
⚠ Second traffic interruption — brief failover.
Install & reboot secondary Auto
Same install + recovery process as the primary. Waits for
show chassis-ready: yes on the secondary.
Verify secondary passive + state sync complete HA
Same HA state verification as step 7, this time on the secondary. Both devices are now running the new version in a healthy HA pair.
Re-enable preemption + commit HA
Restores preemptive: yes on the primary (only if it was
enabled before the upgrade) and commits. The HA pair is now fully
upgraded and back to its original configuration.
Post-upgrade snapshot & comparison (primary) Auto
Captures and compares pre vs post operational state on the primary.
Upgrade type
HA pair upgrade (Azure VM-Series)
The same failover-based upgrade as a standard HA pair, adapted for Azure VM-Series firewalls where the public IP moves with the active unit.
Pre-flight checks + Azure HA auth test Optional
Runs the same pre-flight checks as a standard HA pre-check on both
devices, plus an extra Azure HA authentication check:
it reads the device's configured
vm_series azure-ha-config (client ID, client secret,
resource group, subscription ID, tenant ID) and asks PAN-OS to test
that it can authenticate to Azure with them. This must pass — the
failover steps below depend on PAN-OS being able to call the Azure API
to move the public IP.
Config backup, content update, preemption, software download Auto
Identical to the standard HA pair flow — backup, pre-snapshot, content sync, preemption disable, and software download all work the same way regardless of cloud vs on-prem.
Suspend primary → wait for public IP re-association Azure
Suspends the primary the same as standard HA, but also waits for the
Azure public IP to finish moving to the secondary before proceeding —
confirmed by watching the device's pan_vm_plugin.log for
the re-association event, up to the configured Azure failover
timeout (default 300s). This prevents the upgrade from moving
on while inbound traffic is still mid-cutover in Azure's network.
⚠ First traffic interruption — includes Azure IP cutover time, not just PAN-OS failover.
Install primary → suspend secondary → install secondary Auto
Same install/reboot/state-sync sequence as standard HA. The secondary's suspend step also waits for its own Azure IP re-association back to the primary before the upgrade is considered complete.
Re-enable preemption + post-upgrade snapshot HA
Same wrap-up as standard HA: preemption restored if it was originally enabled, then a post-upgrade snapshot and comparison on the primary.
Upgrade type
Panorama upgrade (single or HA pair)
Upgrades the Panorama management appliance itself — not the firewalls it manages. Same overall shape as a firewall upgrade, with Panorama-specific pre-flight checks and no content-update step.
Panorama pre-flight checks Optional
A different check set from the firewall one, because a Panorama has no dataplane and no vsys. Hard failures (these stop the upgrade): the target is actually a Panorama, managed devices are connected, HA state is as expected, and the upgrade path is valid. Advisories (reported, never blocking): log-collector connectivity, disk space on the image partition, preferred-release info, and managed-device version spread.
Disk space is checked as free gigabytes, not just percent used — a partition at 78% can still be too small for a 600–900 MB image.
Config backup & pre-upgrade snapshot Auto
Exports the running config, then records Panorama state: managed devices and their connection status and software versions, log collectors, licenses, and disk usage. This is what the post-upgrade comparison is measured against.
Download & install → reboot Auto
Downloads the target version, installs it, and reboots. Long installs that outlive the API session are recovered the same way as a firewall upgrade. Panorama's own perpetual background jobs (device-group and template pushes, commit-alls, log-collector housekeeping) are recognised so they don't block the install.
There is deliberately no content-update step — content updates are a firewall concern and are not part of a Panorama software upgrade. That is why the progress bar shows four phases here rather than five.
⚠ Panorama reboots. Managed firewalls keep passing traffic but are unmanaged until it returns.
Post-upgrade snapshot & comparison Auto
Waits for Panorama to come back and for managed devices to reconnect, then re-collects state and compares. Flags devices or collectors that were connected before but aren't now. Devices reconnect on their own schedule, so a small number still showing disconnected shortly after a reboot is usually worth a re-check rather than an immediate rollback.
Panorama HA pair
Choose Panorama HA for an active/passive pair. The primary is suspended and upgraded first, then rejoins and re-synchronises before the secondary is touched, so one unit is always managing. Preemption is disabled for the duration and restored afterwards. Set Wait between upgrades if you want a soak period after the primary rejoins before the secondary starts.
Pre-checks run against both units and are shown side by side. Snapshots are taken on the primary only — the pair shares one managed-device set and configuration, so a second snapshot would duplicate rather than add information.
Upgrade type
Multi-firewall (batch) upgrade
Upgrades multiple firewalls sequentially or in parallel. Each row in the batch can be a standalone firewall or an HA pair — mix and match in the same batch.
Batch pre-checks — all firewalls Optional
Runs pre-flight checks on all firewalls in parallel. A summary table shows pass/fail per device. You can proceed to the batch upgrade even if some devices fail checks.
Per-entry: full upgrade process
Each entry in the batch goes through the complete single-firewall or HA-pair upgrade sequence, whichever applies:
- Config backup →
config_backup.xml - Pre-upgrade snapshot →
pre_snapshot.json - Content update (latest threat/AV signatures)
- Software download & install + reboot(s)
- Post-upgrade snapshot & comparison →
post_snapshot.json
Each entry gets its own run ID, log, and downloadable files, and shows up separately in run history.
Sequential vs parallel mode
Sequential: one entry at a time. Optionally stops on first failure — a cancelled run counts as a failure for this purpose, so cancelling one entry mid-batch also skips the remaining queued entries. Safe for environments where you want to verify each device before moving on.
Parallel: up to N entries upgraded simultaneously (configurable). Faster for large batches. Each entry is fully independent.
Pre-checks must finish before upgrading
The Proceed to upgrade action for a batch is only available once pre-checks have finished for every entry — this prevents starting an upgrade against a firewall that hasn't been validated yet, and prevents starting the same batch twice.
Around a run
Device inventory
A saved list of firewalls so you don't have to retype IPs for every run. Credentials are never stored on the device record — only connection details.
Nickname, client, role & notes
Each device has a nickname, an optional client/site label, an IP or hostname, per-device proxy settings, and free-text notes. Role is one of Standalone, HA Primary/Secondary, or Azure HA Primary/Secondary.
Pairing HA devices
HA and Azure HA roles can be linked to their partner device. Pairing is symmetric — linking one side automatically links the other back. Deleting a device automatically un-links its partner.
One-click deep links
From the inventory table, jump straight into a pre-filled single firewall, HA pair, or schedule form for that device (or its HA pair) — no need to look up the IP addresses again. HA deep-links resolve to the correct primary/secondary order regardless of which row you click.
Auto-updated after a successful upgrade
When a single-firewall or HA upgrade run finishes
successfully, the portal automatically stamps
Last Known Version and Last Upgraded on any
inventory device(s) matching the upgraded IP address(es) — no manual
editing needed. Over time this turns the inventory page into a live view
of what version every firewall is running.
Saved credentials (optional, encrypted)
Each device can optionally store an admin username and password so the upgrade, pre-check, and schedule forms don't need them retyped. The password is encrypted on the machine (Windows DPAPI), is never displayed again, and is never sent to the browser. Devices with saved credentials show a key icon — deep-linked forms then say "leave the password blank to use saved credentials". Typing a password always overrides the saved one, and a clear-credentials button removes them at any time. HA pairs share credentials — saving them on either unit covers both.
Around a run
Scheduling upgrades
Queue a single, HA, or Azure HA upgrade to run automatically at a future date and time — for after-hours maintenance windows.
Pick a type, time, and optional force mode
Choose single firewall, HA pair, or Azure HA, enter credentials and target version, and pick a date/time. Checking Continue upgrade even if pre-checks fail means pre-checks still run and are logged, but a failed check won't abort an unattended overnight run.
A background scheduler fires the job
A scheduler thread checks every 30 seconds for jobs whose time has arrived and starts the full upgrade workflow automatically — pre-checks, backup, snapshot, content update, install, and post-snapshot, exactly like a manually-started run. Progress shows up under the job's row and also in run history.
Jobs survive a server restart
Scheduled job details (device, version, time, options) are saved to disk, so a restart no longer silently loses a queued maintenance window. With Keep credentials with this job checked (the default), the password is stored encrypted alongside the job and it re-arms itself automatically after a restart — nothing to do. If you uncheck it, credentials stay in memory only: after a restart the job shows Needs Credentials and you re-enter the password on its row to re-arm it. Either way, if the scheduled time passed while the server was down, the job is marked failed and must be rescheduled.
Around a run
Run history & cancelling a run
Every run — single, HA, batch, or pre-check-only — is recorded so you can find it again, download its report, or clean it up later.
Filter, search & success-rate summary
The history page lists every run newest-first with status, device, version, duration, and a link back to its status page or report. Filter by status or run type, and see an overall success-rate tile across all recorded runs.
Deleting old runs
Finished runs can be deleted to free up disk space (this removes the run's log, snapshots, and config backup along with its history entry). A run — or a batch with any entry still in progress — cannot be deleted while active.
Cancel run
A Cancel run button appears on the status page while a run is active. Cancelling terminates the current step's process and marks the run Cancelled in history.
⚠ If the cancelled step had already sent an install or reboot command to the firewall, that command may still complete on the device itself — cancelling stops the portal's workflow, not necessarily an in-flight PAN-OS job. Always check the firewall directly after cancelling mid-install.
Around a run
Email notifications
Get an email when an upgrade finishes — most useful for scheduled overnight runs where nobody is watching the status page.
Pick a provider or use a custom SMTP server
The settings page has one-click presets for Office 365 / Outlook, Gmail, and Yahoo Mail (host, port, and encryption auto-fill), or choose Custom to point at any other SMTP relay — internal or external.
App passwords for Gmail & Yahoo
Gmail and Yahoo require an app password (not your normal login password) when two-factor authentication is enabled on the account. Office 365 accounts may need "Authenticated SMTP" turned on by an administrator.
Choose recipients & when to notify
Enter one or more comma-separated recipient addresses, and choose whether to be notified for every completed upgrade or failures only. Use Send test email after saving to confirm the server settings work before relying on them for a real maintenance window.
Fires for single, HA, and batch runs
A notification is sent when a single-firewall or HA upgrade run finishes (success, failure, or cancelled), and one summary email is sent per completed batch listing every firewall's result — not one email per firewall in the batch.
Before you begin
Important notes
One upgrade per run, but jumps are allowed
A run performs one upgrade — it does not chain several hops together. That does not mean one release at a time: from PAN-OS 10.1 and above, Skip Software Version is supported, so 11.1.x straight to 12.1.x is a single run. Each starting version has a documented ceiling, and the pre-flight check verifies yours — if the jump is too far it names the version to go to first.
Base images are handled for you. If the target needs
one, it is downloaded automatically before the install — downloaded
only, never installed. This includes release trains with no
.0: the base for 12.1 is 12.1.2, which is
identified by image size rather than assumed from the version number.
Below PAN-OS 10.1 there is no Skip Software Version, so those upgrades really are one release at a time. The pre-flight check says so and lists the path.
HA with preemption
The HA upgrade process disables preemption automatically before upgrading. If preemption is already disabled, this step is a no-op. HA pairs with preemption that cannot be temporarily disabled are not supported.
Session-timeout recovery
PAN-OS closes the API session during long installs (15–30 min).
The portal detects this, waits for the install job to complete on the
device, confirms SWInstall result: OK, and sends the reboot
command. This is normal — the [RECOVERY] message in the log
is not an error.
Credential caching
When you run pre-checks first and then click proceed (single, HA, or batch), credentials are cached in memory for 30 minutes. After that the session expires and you must re-run the checks — expired entries are actively swept from memory rather than waiting for a server restart. Credentials are also cleared from memory as soon as the run they belong to completes.
Night Agent is an Early Access Beta
It is functional software that is still being tested and improved through real-world feedback. Features, workflows and requirements may change, and it may contain defects or incomplete functionality. Evaluate it in a lab or non-critical environment before using it against production systems.
Firewall upgrades can interrupt service, change configuration, or cost you management access. Night Agent runs the checks and the sequence, but it cannot remove those risks: review the upgrade path, keep a current config backup, use an approved maintenance window, confirm you have recovery access, and watch the firewall while it runs.
Night Agent does not guarantee a successful upgrade, uninterrupted service, compatibility with every environment, or zero downtime.
See Night Agent on your own firewalls
Enter your email and we'll send you a license key and a download link straight away. No sales call, no card.
Early Access Beta · 30-day trial · No card required