Updating self-hosted AI: can it be done safely?

#The longer you wait, the heavier the update gets

The notice says a new version is out, yet the server is still sitting several versions back. That is a familiar picture at companies running on-premises software. It's hard to tell what changed in the new version, a failed update can take the service down, and the only record of how to roll back is in one person's head. Skip a few versions like that, and the next update has to step through each intermediate version in turn, which makes it heavier still.

In OwlAI, a single approval in the admin console applies the update. The confirmation dialog shows what changed and how to roll back before you approve, and the updater on the server handles both applying the update and rolling it back if it fails.

#A file with a bad signature never reaches the confirmation dialog

We sign every OwlAI release before it ships. The server checks the signature on the file it receives first, and if the signature does not match, it deletes the file without opening the confirmation dialog. A file that someone has swapped out, or that was corrupted in transit, does not get installed.

You always move to a single version: the latest one. There is no list of versions to pick from and no intermediate version to pass through, so even after skipping several versions you reach the latest in one step.

#Without an administrator's approval, the new version does not get in

If your installation can reach the internet, an Update button appears in the admin console when a new version is released. On an air-gapped network, you upload the single release file you received. From there, the process is the same.

The confirmation dialog shows only what you need to decide: the current and new versions, how the service is affected while the update is applied, how to roll back if something goes wrong, the backup scope, and what changed. The administrator confirms their identity once more with their current password before approving, and enters an authentication code as well if the account has two-factor authentication turned on. If nobody approves, the new version does not get in.

After approval, the updater on the same server applies the update in a fixed order. It backs up the database automatically right before applying, and before swapping the services it waits for in-progress answers and analyses to finish. Progress appears on screen step by step. If the server reboots or loses power partway through, the updater resumes from the step where it stopped.

#When an update fails, the updater rolls back on its own

If the new version does not come up properly, the updater rolls back to the previous version and records the result, with the reason, in the history table. Nobody has to remember the rollback steps.

If a problem shows up after the update has finished, there are two paths. When the database structure is compatible with the previous version, a single provided command takes you back to it. When the version changed the structure, you restore from the backup taken right before the update. Which path applies to this version is already shown in the confirmation dialog before you approve.

The pre-update backup covers the database. Because an update changes the program and the database structure, that one backup is all you need to get back to where you were just before the update. Updates do not touch documents or generated files. The pre-update backup does not replace regular backups; regular backups that protect the database together with documents and generated files run on your company's own backup system.

#Most screens stay usable during an update

The impact while an update is applied differs from version to version, and the confirmation dialog shows it in advance. In most cases the screens stay usable and in-progress answers wait a few minutes. If a version may cause errors for a few minutes while services are swapped, or pauses for tens of minutes depending on data volume, the dialog warns you and advises applying it during low-usage hours. If the screen connection drops briefly, it reconnects on its own, and desktop apps on employees' PCs pick up the new screens once the server update finishes; they download a new installer only for versions that change the app's underlying program.

In SaaS, OwlAI handles updates, so customers have nothing to do. On-premises, read two lines in the confirmation dialog before you approve, the impact during the update and the rollback path, and pick a time to apply it based on them.