LogZilla

LogZilla upgrades run in place. The logzilla upgrade command pulls the new container images, applies any database and configuration migrations, then decommissions the running containers and starts the new ones. Most upgrades complete within a few minutes. Event data, dashboards, triggers, users, and configuration are preserved across the upgrade.

All upgrade commands require root privileges and are run on the LogZilla server host, not inside a container.

Before Upgrading

Confirm administrative (root) access on the LogZilla server.

Check available disk space for Docker. The upgrade downloads new images before removing the old ones, so both sets coexist briefly:

bash
docker info --format '{{.DockerRootDir}}' | xargs df -h

Create a backup of the server, or a snapshot of the virtual machine, so the deployment can be restored if a rollback is needed. Downgrading LogZilla is experimental and is not a substitute for a backup.
Note the current version so the result can be confirmed afterward.

Check the Current Version

Print the installed version before starting:

bash
logzilla version

To see every version available for the current release channel:

bash
logzilla upgrade --list

Standard Upgrade

To upgrade to the most recent available release, run:

bash
sudo logzilla upgrade

This selects the latest version on the current release channel, downloads its images, runs migrations, and restarts the services in place. A successful run ends with a confirmation line:

text
Starting LogZilla upgrade to 'v6.42.0'
...
LogZilla successfully upgraded to 'v6.42.0'

When an upgrade is available, the web interface also displays a notification with a button that copies the upgrade command to the clipboard.

Upgrade to a Specific Version

To upgrade to a chosen release rather than the latest, pass --version with the target tag:

bash
sudo logzilla upgrade --version v6.42.0

Use logzilla upgrade --list to find the exact tag to supply.

Upgrading From Older Releases

A single logzilla upgrade can move a deployment across several releases at once. However, when a deployment is several versions behind, upgrading through intermediate releases may be needed. Each step keeps the volume of database and configuration migrations small and lets the result be verified before moving on. Target each release in turn with --version:

bash
sudo logzilla upgrade --version v6.35.1
sudo logzilla upgrade --version v6.38.1
sudo logzilla upgrade

Deployments older than v6.26.1 must first upgrade to v6.26.1. Upgrading directly from a release older than v6.26.1 is not supported, and the platform stops the upgrade with instructions to run:

bash
sudo logzilla upgrade --version v6.26.1

After reaching v6.26.1, continue to the desired release using the steps above.

Verify the Upgrade

Confirm the new version is running:

bash
logzilla version

Confirm the API is responding:

bash
curl http://localhost/api/ping
{"detail":"ok"}

Then log in to the web interface and confirm that authentication, dashboards, and search behave as expected.

Downgrades and Channel Changes

Downgrading to an earlier version is experimental and may result in complete data loss. The platform prompts for confirmation before proceeding. Switching between release channels (for example, from a release-candidate build to a stable build) is also experimental and prompts for confirmation.

Air-Gapped Upgrades

Servers without direct internet access upgrade from a downloaded offline package using logzilla upgrade --offline-dir. For the full procedure, see Offline Installs and Upgrades.

Release Notes and Lifecycle

Review the changes in each release, and the end-of-support and end-of-life dates that determine when an upgrade is required, on the Software Lifecycle and Release Notes page.

If an upgrade does not complete, see Troubleshooting.