This document explains how a panel update is offered and started, what the Updates page shows, what is kept for a rollback, what happens when a step fails and how to go back to the previous version.
Updates come from the license server at https://api.xtreamgo.io. Some messages on the Updates page use another name for this server. This document quotes those messages and gives their meaning.
Before you start
- Take a database backup before every update. A new version can change the database structure when it starts. No rollback step restores the database. See Backup and restore.
- Updates are delivered by the license server over SSH. It needs valid SSH access details for your server. Read the section "SSH access for updates".
- Keep a few GB of free disk space. The new images are copied to the server and loaded next to the running ones. Old images are removed only after a successful update.
- Your license must be active. The update request must come from the IP address the license is bound to.
- Only users of the administrator groups can start an update.
How an update is offered
- The panel asks the license server for the newest published release and sends its own running version. This happens when the dashboard loads, every 4 hours while it stays open, each time you open the Updates page and when you press Check for Updates.
- When a newer release exists, the dashboard shows an update notice with the button Update Now. The button opens the Updates page.
- The Updates page is in the sidebar group Setup & Migration under the entry New Updates. Its address is
/dashboard/updates. - The page shows Update Available, the Current and the Latest version, the release type and the release notes. The notes are grouped as New Features, Bug Fixes and Improvements.
A panel that already runs the newest release shows System is Up to Date, its version and the time of the last check.
How an update is started
- An administrator presses Install Now on the Updates page.
- The panel sends an update request with its license key to the license server.
- The license server checks the request. The license must be active, the request must come from the bound IP address, SSH details must be registered for the license and no other update may be running for the license.
- The license server connects to your server over SSH and carries out the update. The page shows the live progress.
The update is a push from the license server. Your panel does not download images by itself. The xtreamgo update command on the server does not download a new version either. See Install the main server.
The buttons Tonight (03:00), Tomorrow Night and This Weekend are not active. The page says Scheduled updates are coming soon. Use Install Now to update immediately.
SSH access for updates
Updates are delivered by the license server over SSH. It logs in to your server with the server access details registered for your license: the SSH port, the user and the password. The password is stored encrypted. The install directory defaults to /home/xtreamgo.
How the access details are registered:
- If you bought the panel with the automatic setup on the XtreamGo website, the SSH details you entered at purchase are registered for the license.
- If you installed the panel yourself with
install.sh, no SSH details are registered. An update request fails until they are. Ask XtreamGo support to register the SSH details for your license. - The function to change the server in the customer dashboard also registers the SSH details of the new server. See License.
What you must keep valid:
- Password login for the registered user must be allowed on the server.
- The SSH port must be reachable from the license server.
- If you change the SSH password or port of the server, updates fail with
SSH connection failed. Check the panel's SSH settings and network.until the registered details are corrected. - If you reinstall the operating system, the SSH host key of the server changes. Updates then fail with
The panel server's SSH key changed. If the server was reinstalled, save its SSH settings again to accept the new key.until the details are registered again.
To change or renew the registered details, contact XtreamGo support.
When the license server does not accept an update request, the Updates page shows Could not reach CMS. Please update from CMS panel → Releases → Deploy. The name in this message means the license server. The page named in the message is not available to operators. Contact XtreamGo support when you see this text. The usual causes are listed in the section "If something goes wrong".
What the update does on your server
A release names its components. The default is api and frontend. A release can also include portal.
Every release installs exact, fixed images. The license server does not send whatever image is newest at that moment. For each component it sends the image that was recorded for the release, and your server checks it twice before use.
| Phase | Action on your server |
|---|---|
| Connection | SSH login test. |
| Version check | Reads the running version from http://127.0.0.1/api/v1/build/info. A panel that already runs a newer version is never moved back to an older one. Checks that docker-compose.yml exists in the install directory. |
| Transfer | Copies each image to /home/xtreamgo/.xg-update-<component>.tar.gz. |
| Integrity check | Compares the SHA-256 sum of the file, loads the image into Docker, removes the file and checks that the loaded image is the one recorded for the release. A mismatch stops the update before any service is touched. |
| API switch | Runs scripts/deploy_zero_downtime.sh. The script starts the new API container next to the running one, waits up to 600 seconds for its health check, adds it to nginx, moves the traffic, checks that requests reach the new container, waits 10 seconds for open requests and stops the old container. The update then waits until the panel reports the new version. |
| Admin interface and portal | Tags the image that the running container uses as xtreamgo-frontend:rollback-pre-update or xtreamgo-portal:rollback-pre-update. Recreates only that service with docker compose up -d --no-deps and .env.production. Waits until the login page answers through nginx. |
| Maintenance scripts | Refreshes db_lb_access_sync.sh and setup_db_lb_access.sh in /home/xtreamgo/scripts. A failure here does not fail the update. |
| Image cleanup | Removes old xtreamgo-api, xtreamgo-frontend and xtreamgo-portal images. See "What is kept for a rollback". |
| Final check | Calls http://127.0.0.1/health and reads the version again. The result is recorded with the update. |
The API runs in two alternating containers named xtreamgo-api-blue and xtreamgo-api-green. This is called blue/green mode: the panel keeps the previous API version stopped next to the new one so it can switch back. After the first update the original container xtreamgo-api is stopped and kept.
After a panel update the panel also refreshes the agent program on your own load balancers. The agent accepts only a signed file and restores its previous version when the new one does not stay up for 60 seconds.
What is kept for a rollback
| Item | Where | Kept until |
|---|---|---|
| Previous API | The previous API container stays on the server in the stopped state. The file /home/xtreamgo/nginx/.bg-rollback.meta records its name, its slot and its image ID. | The next update. The next update replaces it with the version that was live before that update. |
| Previous admin interface | Image tag xtreamgo-frontend:rollback-pre-update. | The next update that includes the admin interface. |
| Previous customer portal | Image tag xtreamgo-portal:rollback-pre-update. | The next update that includes the portal. |
| Database | Not kept. | Take your own backup before the update. |
The image cleanup at the end of an update never removes an image that a container uses, running or stopped. It also keeps the latest tags, the two rollback-pre-update tags and the images of the release just installed.
A rollback therefore stays possible after a successful update. It goes back one version, not further.
What the Updates page shows
During an update the page shows a progress card with a percentage, the elapsed time, the label Live from the CMS and the text of the current step. The name in this label means the license server.
| Element | Meaning |
|---|---|
| System is Up to Date | No newer release is published. |
| Update Available, Current, Latest | A newer release exists. |
| Check for Updates | Asks again. |
| Install Now | Sends the update request. |
| Applying update... | Title of the progress card while the update runs. |
Connecting to CMS | Milestone 1: the license server connects to your server over SSH and checks the version. |
| Downloading new version | Milestone 2: images are prepared, transferred and checked. |
| Zero-downtime switch (blue → green) | Milestone 3: the API moves to the new container. |
| Updating interface | Milestone 4: the admin interface container is replaced. |
| Health verification | Milestone 5: maintenance scripts, image cleanup and final check. |
| Restoring the previous version | A step failed after a service was switched. The previous version is being put back. |
Version <version> is installed | Title of the progress card after success. |
Update completed, Your panel is now running <version>., Done | The update finished. The page reloads when you press Done, or by itself after 12 seconds. |
| Update failed | The update ended with an error. The card shows the reason. |
You can leave the Updates page during an update. The update is driven by the license server and continues. The dashboard shows Update in progress… with a link View status, and the Updates page shows the live progress again when you return.
During the API switch viewers and the panel stay connected. The admin interface container is recreated, so the browser can lose the page for a short moment.
What happens automatically on failure
| Where it fails | Result |
|---|---|
| SSH login, version check or install directory check | Nothing is changed. |
| Transfer or integrity check | The update stops. A service that was already switched in the same update is put back. |
| API health check | The new API container is removed. The running API container was never touched. Script message: ROLLBACK, with the text old slot (...) is still serving traffic, no customer impact. |
| nginx switch or acceptance check | The script restores the previous nginx configuration and keeps the old API container in service. |
| The panel does not report the new version after the switch | The API is switched back to the kept container with scripts/fast_rollback.sh. |
| Admin interface or portal does not start | The service is set back to its rollback-pre-update image and recreated. If the API was switched in the same update, the API is switched back as well. The panel never keeps a new interface next to a restored API. |
The Updates page then shows one of these results:
- The reason alone, for example
The new API did not pass its checks; the panel kept running the old API. Nothing was switched, so nothing had to be restored. When no reason is available the text isThe update stopped before anything was changed on your panel. The update did not pass its checks, so the previous version was restored. Your panel keeps running as before.followed by the reason. A service was switched and the automatic restore succeeded.- A reason that ends with
Restoring the previous version failed too; check the panel now. The automatic restore did not complete. Contact XtreamGo support at once and do not restart containers yourself.
How to request a rollback
The panel has no rollback button. There are two ways.
Ask XtreamGo support
Write to XtreamGo support and name your license and the version you updated to. Support starts a rollback for your panel over the same SSH access as an update. The rollback:
- Runs
scripts/fast_rollback.shto switch the API back to the kept container. - Sets the admin interface and the portal back to their
rollback-pre-updateimages, where such an image exists. - Reads the panel version before and after.
If no kept API container exists, or it fails its checks, the rollback stops and the current API keeps running.
Do it on the server
API:
cat /home/xtreamgo/nginx/.bg-rollback.meta
bash /home/xtreamgo/scripts/fast_rollback.shThe script works when the file .bg-rollback.meta exists. It checks that the kept container still has the recorded image, starts it, waits up to 60 seconds for its health check, moves the traffic, checks that requests reach the old version and only then stops the newer container. It ends with Fast rollback complete: now serving '<slot>'.
Admin interface (use portal in place of frontend for the customer portal):
cd /home/xtreamgo
docker image inspect xtreamgo-frontend:rollback-pre-update >/dev/null && \
docker tag xtreamgo-frontend:rollback-pre-update xtreamgo-frontend:latest && \
docker compose --env-file .env.production up -d --no-deps frontendA rollback by XtreamGo support runs the same commands. Keep --no-deps. Without it Docker Compose also starts the original xtreamgo-api container next to the live one.
Limits of a rollback:
- It does not restore the database. If the newer version changed the database structure, the older API may not work with it. Restore your backup from before the update in that case, or contact XtreamGo support first.
- The API rollback works once. After a rollback the file
.bg-rollback.metais removed. - It goes back one version only.
Manual installation of an update
An update cannot be installed by hand. New versions arrive only through the Updates page. xtreamgo deploy [image] only switches to an API image that is already loaded on the server. Otherwise it stops with a message that starts with image '<name>' not loaded.
How to check the running version
curl -s http://127.0.0.1/api/v1/build/info
docker ps --filter name=xtreamgo- --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
sed -n '/BG_UPSTREAM_BEGIN/,/BG_UPSTREAM_END/p' /home/xtreamgo/nginx/nginx.conf
cat /home/xtreamgo/nginx/.bg-rollback.meta 2>/dev/null
docker images | grep -E 'xtreamgo-(api|frontend|portal)'Expected results after an update:
build/infoshows the newversion, theslot(blueorgreen) and a recentstarted_at.- Exactly one running API container, with status
healthy. - The upstream block names only the running API container.
.bg-rollback.metanames the stopped container of the previous version.- The image list shows the tag
rollback-pre-updatefor each interface service that was updated. - The Updates page shows System is Up to Date and the new version.
If something goes wrong
| Message | Where | Meaning and action |
|---|---|---|
Could not reach CMS. Please update from CMS panel → Releases → Deploy. | Updates page | The name in the message means the license server. It did not accept the request, or the panel could not reach it. Causes: no connection, no registered SSH details, IP mismatch, inactive license. Check curl -sI https://api.xtreamgo.io from the server, then contact XtreamGo support. |
Request source IP does not match license bound IP | License server | The server sends requests from another public IP than the bound one. See License. |
No published release available | License server | Nothing to install. |
License is not active (status: ...) | License server | Renew or reactivate the license. |
SSH connection failed. Check the panel's SSH settings and network. | Updates page | The registered SSH details are wrong, or SSH is blocked. Correct them with XtreamGo support. |
The panel server's SSH key changed. ... | Updates page | The server was reinstalled. Ask XtreamGo support to register the SSH details again. |
The panel runs <a>, newer than <b>. Older versions are never installed over newer ones. | Updates page | The panel is already ahead of the release. No action. |
The panel install directory was not found (...) | Updates page | The install directory registered for your license has no docker-compose.yml. Contact XtreamGo support. |
The <component> image failed its integrity check on the panel; nothing was changed | Updates page | The transferred file was damaged or did not match the release. Check free disk space and start the update again. |
The panel has no zero-downtime deploy script; nothing was changed | Updates page | /home/xtreamgo/scripts/deploy_zero_downtime.sh is missing or not executable. Contact XtreamGo support. |
The new API did not pass its checks; the panel kept running the old API | Updates page | The new API did not become healthy or failed the switch. The old API serves the panel. Send the output of the check commands to XtreamGo support. |
Another update is already running for this panel | Updates page | Wait until the running update ends. |
Interrupted: the CMS restarted during this job. Check the panel version, then start it again. | Updates page | The name in the message means the license server. The update was interrupted there. Check the version with the commands above, then press Install Now again. |
[fail] another blue-green deploy is in progress on this host | Deploy script | A previous run still holds the lock. Wait. If no update runs, contact XtreamGo support. |
[fail] ENV-FILE MISMATCH | Deploy script | The running API container was started with a database password that differs from .env.production. The rest of the line is in Turkish. Contact XtreamGo support. |
[fail] no rollback manifest at ... | fast_rollback.sh | No kept container exists. A manual API rollback is not possible. |
[fail] DIGEST MISMATCH: preserved container image ... != manifest ... | fast_rollback.sh | The kept container no longer matches the record. The script refuses. Contact XtreamGo support. |
[fail] rollback container did not become healthy | fast_rollback.sh | The older API does not start, often because of the database structure. The current API stays in service. |
[fail] ROLLBACK ABORTED | fast_rollback.sh | The old version failed the acceptance check. The newer version was put back in service. |
A file /home/xtreamgo/.xg-update-<component>.tar.gz remains | Server | An update stopped while the image was loaded. Leave it in place and contact XtreamGo support. |