Document CMS Software Update panel and permissions

- Explain enabling Software Update (gru) in Users Permissions before panel use
- Describe install-only, install+trigger reload, and up.sh-only options
- List required .env settings, log paths, and manual SSH equivalents

README.md

@@ -121,3 +121,55 @@ cd /home/www/callcenter/deploy
 ```bash
 ./rubix_deploy_from_release.sh vX.Y.Z
 ```
+
+## Software Update (CMS admin panel)
+
+After the stack is running, app updates can be done from the call center admin UI instead of SSH.
+
+### 1) Grant permission to the admin user
+
+The user who should run updates needs the **Software Update** permission enabled.
+
+1. Log in as a superadmin (or another user who can edit permissions).
+2. Open **Management → Users Permissions** (search: `Users Permissions`).
+3. Select the target admin user.
+4. Enable **Software Update** (`gru`) and save.
+
+Without this checkbox, the **Software Update** panel is hidden and API calls return *No Software Update permission (gru)*.
+
+### 2) Open the panel
+
+**Management → Software Update** (popup). The panel reads the installed version from `VERSION`, compares it to the latest release on Gitea (`RUBIX_GIT_RELEASE_URL` in `/etc/rubix/.env`), and shows deploy logs.
+
+Required in `/etc/rubix/.env`:
+
+- `RUBIX_GIT_RELEASE_URL` — e.g. `https://gitea.dialer.work/swissdatabase/rubix/releases/latest`
+- `RUBIX_GIT_TOKEN` or `GITEA_REGISTRY_PULL_TOKEN` — token with read access to releases
+- `RUBIX_PANEL_HOST_UP_ENABLE=true` — show host reload buttons (default: enabled)
+
+Logs (under the install path):
+
+- `deploy/rubix_deploy.log` — panel ZIP deploy
+- `deploy/rubix_host_up.log` — host `up.sh` (when triggered)
+
+Use **↻ Reload logs** to refresh both logs in the panel.
+
+### 3) Update options
+
+| Button | What it does |
+|--------|----------------|
+| **Install latest release** | Downloads the release ZIP from Gitea, syncs files into `/home/www/callcenter`, runs SQL migrations from the CMS container. Does **not** restart Docker services on the host. |
+| **Install latest release and trigger reload** | Same as above, then queues `deploy/docker/up.sh` on the host (root cron, ~1 min). Restarts/refreshes the stack: Docker compose, MySQL users, firewall, host cron, SQL migrations via `docker exec`, certbot, fail2ban, etc. |
+| **Trigger reload (up.sh only)** | No ZIP deploy. Only queues `deploy/docker/up.sh` on the host (root cron). Use when code is already up to date but you need containers/services refreshed and DB migrations applied on the host. Available even when no newer release exists. |
+
+**Install latest release** = code + migrations inside CMS.  
+**Trigger reload** = full host stack reload via `sudo ./up.sh` (panel cannot run it directly; root cron picks up the request).
+
+Manual equivalent on the server:
+
+```bash
+cd /home/www/callcenter/deploy
+./rubix_deploy_from_release.sh vX.Y.Z          # panel “Install latest release”
+# or
+cd /home/www/callcenter/deploy/docker && sudo ./up.sh   # panel “Trigger reload”
+```