Update Reportworq#

Settings > Update Reportworq is the in-product way to keep an instance current. It lists available software versions and updates the instance to the latest official release, the latest hotfix, a specific version, or from a patch file. Update actions download and install builds and restart the service, so they are administrator-only and should run in a maintenance window.

Before you begin#

• System-administrator rights.
• A maintenance window, updates restart the service and interrupt active reporting.
• For online methods, connectivity to the update source. For an isolated server, a patch file provided out of band.
• A backup, see below.

Back up before you update#

1. Create a timestamped backup from Settings > Configuration > Web Server > Backup, then select Create backup. Reportworq writes a dated archive (for example reportworq_data_backup_2024-10-05 20.41.38.zip).
2. Note the Bootstrap Service startup type and logon account.

Modern upgrades also auto-back-up the Repository before applying. Keep the pre-upgrade backup: occasionally an upgrade introduces non-backward-compatible database changes, so downgrading past such a build is unsafe.

If you need to downgrade, or a downgrade does not behave as expected, contact Reportworq support before going further. Reversing a version that changed the Repository is not a self-service operation, and support can tell you whether the build you are on is one of the affected ones.

Restore from a backup#

Reportworq has no in-product restore button; a restore is a manual file operation. Do it with the service stopped so no process holds the Repository open, the same discipline used when moving servers.

1. Stop the Reportworq 6 Bootstrap Service on the server (services.msc).
2. Extract the backup archive's contents into the Repository folder, replacing the current contents.
3. Start the Bootstrap Service.
4. Sign in and confirm jobs, schedules, and datasource connections are intact.

Update Reportworq#

1. Open Settings > Update Reportworq. The versions grid loads in the background; use Refresh if it is empty or slow.
2. To see hotfix builds, turn on Show Hotfix Versions. A hotfix is a fully tested update to the current official version that contains only critical fixes, no new features and no experimental changes. Hotfixes are hidden by default and applied on support's guidance.
3. Open the Update menu and choose a method:
   • Update to latest official version, installs the newest official release.
   • Update to latest hotfix version, installs the newest hotfix build (shown only when hotfixes are visible).
   • Download a specific version, targets a chosen version from the grid.
4. The update installs and restarts the service. Confirm the new version on the Settings landing card afterward.

Update an air-gapped instance#

When the server cannot reach the update source, update from a patch file provided out of band.

1. On an internet-connected machine, download the patch file (Reportworq_Patch_<version>.zip, for example Reportworq_Patch_5.0.0.75.zip) for the target version.
2. Transfer it to the server.
3. In Settings > Update Reportworq, open the Update menu and choose Update from a patch file, then select the transferred file. The upload shows a progress indicator while it applies.
4. The update installs and restarts the service. Confirm the new version on the Settings landing card.

Update a Docker or Azure App Service deployment#

Self-hosted Docker updates the same way as Windows and Linux. Settings > Update Reportworq shows the normal Update menu and the per-row activate, remove, and download actions, and you install a version from the grid, the latest official release, the latest hotfix, or a specific version, the same steps as above. The container image itself stays read only, so the version you install downloads to the container's persistent storage rather than the image, and the restart the update triggers brings the new version up. Because the image tag does not change when you update this way, the running version can differ from what the tag on the image says; the versions screen and the Settings landing card always show what is actually running. If you prefer to manage versions at the container level instead, that still works too: swap the image tag and restart.

Azure App Service is different, because App Service re-pulls its own image on every recycle. A version installed from inside the app would be silently reverted the next time the platform recycled the instance, so on App Service the Update Reportworq screen stays informational:

• The Update menu and every per-row activate, remove, and download action are hidden.
• A callout reports the running version and explains that App Service updates by changing the container image.
• The version grid stays visible, read only, so you can still see what is running and what exists.

On App Service, update at the container host instead. Change the App Service container setting to the image tag you want and restart. The new image is the update, and the Repository on its mounted storage carries your content across unchanged.

Update worker nodes the same way you update the web instance, and keep every node on the same version.

Why App Service is different. Its filesystem is replaced from the image on every recycle, so an in-app update there would be undone by the platform before it mattered. Self-hosted Docker does not recycle that way, so Reportworq lets it use the normal in-app update path instead. See Deployment topology.

Update a load-balanced cluster#

All servers in a cluster should run the same Reportworq version, so update them together in a maintenance window.

1. Update the main server first, using the steps above.
2. Update each load-balancer node to the same version.
3. Coordinate the node restarts so jobs are not dispatched to a node mid-update. On the Load Balancer screen, a node's Status reflects whether it dequeued a job in the last two minutes; let nodes settle before and after each update.

See Deployment topology for the cluster model.

Notes and limits#

• Update actions are disruptive (install plus restart) and should not run during active reporting.
• Software-version and restart events are recorded in the System audit log under the Informational category, see Audit logs.

Going deeper. The backup-and-restore-into-Repository discipline here is the same one used when moving servers, see Migrate to a new server.