One-click updates (and the beta channel)

In short. An update is started from Administration → Agora, in a few clicks. Agora takes a full backup of its database before touching anything, and automatically goes back to the previous version if the new one does not start. It works the same with Docker, with a panel and on a Node.js server.

Before you start #

• Be an administrator of your Hub and sign in: the update is done from the admin area.
• Your license must be neither expired nor locked: otherwise the button is missing, see Understanding your license state.
• The server needs a little disk space: the pre-update backup is written there. Database, backup, migration: the words are in the glossary.

Steps #

1. Open Administration → Agora. A "version available" badge on the tab lets you know (automatic check every 6 hours). Click Check now if needed.

   <!-- CAPTURE C-076 -->

2. Read What's new. Two notes may appear: Important update (security) and Includes database migrations.

3. Click "Update to X.Y.Z".

4. Follow the steps on screen: backup, download, verification, migrations, restart. The site restarts during the update.

   <!-- CAPTURE C-077 -->

5. Reload the page at the end. A page opened before the update may say "Agora was just updated": reload it.

   <!-- CAPTURE C-079 -->

6. Redeploy the FiveM resource if its version changed. Server → Players shows the expected version. See Update the resource.

You know it worked when… #

Administration → Agora shows the new version, with no "Last error", and /api/health answers "ok": true.

If it does not work #

When the button is not there #

If the update fails #

The screen shows "Failed:" followed by a plain-language cause (backup impossible, disk full, download refused, migrations refused…), with what to fix. Until the backup is done, nothing is changed. If a message ends with a code, try once more: if it comes back, send that code to support. See Failed update.

<!-- CAPTURE C-081 -->

A cut during preparation. If the application stops before the switch (memory exhausted, server restart during the download), the screen immediately says "the application stopped in the middle of an update" instead of staying on "Downloading…"; nothing was changed, just run the update again. A switch request that was already complete at the time of the cut is played. This finding comes from the supervisor: on an installation that does not yet have the up-to-date image, the screen ends up saying "the previous update was interrupted" after 30 minutes. Before downloading, Agora also checks there is enough free space (about five times the size of the version) and says so rather than failing at extraction.

The automatic check failed? If the last check (every 6 hours) could not complete (update server silent, signature refused, license not eligible), the page says so under the check date, even if it was not your click that failed.

The site stays silent after the update? Wait a few minutes: if the new version does not answer within 3 minutes, Agora puts the previous one back on its own. On a panel, the server's console says why. If the message is about the built-in database, see Troubleshoot the Hub's built-in database.

Going further #

What happens, in order #

Agora keeps the 3 most recent automatic backups. A backup you named yourself is never deleted automatically.

With the built-in database of a panel or Node.js server, the pre-update backup is made the same way and stays in Agora's backup folder. <!-- À CONFIRMER : œuf tout-en-un (claude/pg-integre), BASE-INTEGREE §6 point 5 : mise à jour 1 clic (bascule et repli) avec la base intégrée, non éprouvée sur le banc -->

"It answers" means: healthy, database included. To confirm the new version, Agora does not settle for the site answering: the health page (/api/health) must also announce that the database is reachable ("ok": true). A version that starts but whose database does not answer is not confirmed healthy. A database slow to start has the whole 3-minute window to answer; only a database still unreachable after that delay triggers the return. The return does not repair the database: check that it is running (container, network, credentials), then run the update again.

Where to read the cause of a return. The reliable source is the panel console: the line pas de santé en 180 s … sa base de données restait injoignable names the database. The update screen is served by the fallback version: it can only say "its database did not answer" if that version already contains this change. Otherwise you will see "the new version did not start" even when the database is the cause: read the console then.

If the host itself restarts between the switch and the confirmation (power cut, memory exhausted, docker restart), the database may come back later than the application: only in that case, the version is confirmed on the mere fact that it answers.

No going back. Agora remembers the highest version it has already run and refuses to install anything older, even if the update server offers it (an old signed version would keep its flaws, and database migrations cannot be undone). For the same reason, calls to the license server and the update download follow no redirect.

After restoring an older backup, the same update pass (step Bringing the database up to date after a restore…) brings the database to the level of the running version. This catch-up does not keep the previous version on disk: see Backups and restore.

Rollback restores the previous application; it does not undo database migrations. To go back on the database side, restore the pre-update-… file: see Failed update.

The beta channel #

• Stable (recommended): released versions.
• Beta: test builds, reserved for the Pro tier. Elsewhere the option is greyed out and the instance follows the stable channel.

To change it: Administration → Agora, Channel list. The choice applies as soon as you select it and starts a check right away. For beta, Agora asks you to confirm: these are test builds, and once installed there is no going back (database migrations cannot be undone).

<!-- CAPTURE C-078 -->

There is never a downgrade: if the chosen channel only has a version older than yours, the page says so ("older than your version: nothing to install") and you will get the channel's next version as soon as it passes yours.

If you run a support fix (a 1.8.0-fix.<ref>.<n> version), a fix counts as newer than every beta of its version, so the page never says "older than your version". It compares on the fix's base (1.8.0): any normal version of the channel whose base is at least that stays offered, later betas included. Revert to the normal version then becomes the main button. A version below the fix's base shows "lower than your fix's base: nothing to install". A beta of that base or newer is offered under a fix like a normal version, depending on your channel.

Under a normal version, Revert to the normal version never takes you below the version that is running: the running version acts as a floor.

Update on startup #

Useful when the admin area is not reachable:

• Docker (install.sh): cd /opt/agora && AGORA_UPDATE=1 docker compose up -d
• Panel: set the Mettre a jour au demarrage variable to 1, restart, then set it back to 0.

<!-- CAPTURE C-080 -->

The same rules apply: backup before migrations, return to the previous version on failure. See Environment variables.