deploy.sh, bootstrap.sh, update_host.sh, setup_ssh.sh and pve all carry a
#!/bin/bash shebang and are invoked directly, but git recorded every one of
them as 100644. A fresh clone therefore could not run ./deploy.sh, and any
host where the bit had been fixed by hand showed a permanently dirty
working tree — the mode was the only difference.
Record the bit so a clone is runnable and `git status` stays clean.
The panel update status lived only in-memory and was cleared solely by the
host watchdog restarting the container. If the rebuild failed mid-way (e.g. the
build OOMs the host when no swap is configured), the container never restarted
and the UI stayed at "restarting - 80%" forever.
- update_service: get_update_status() now self-heals — after UPDATE_TIMEOUT_SECONDS
(default 900s) of "is_updating" it transitions to a terminal "failed" state with
a clear error pointing at the host update service / logs.
- use-settings: poll update status while the server reports is_updating (not only
right after the click in the same tab), so reloading a stuck page keeps refreshing.
- SettingsPage: banner now renders the "failed" state with the error message.
- update_host.sh: build images sequentially (app, then frontend) to lower peak
memory and avoid the OOM that killed the build mid-run.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Migrate VMs/LXCs between cluster nodes with live progress tracking
- Configure autostart, boot order, startup/shutdown delays, and delete protection from the instance settings tab
- Group OS templates by detected OS (Ubuntu, AlmaLinux, etc.) instead of a single "Cloud Images" bucket
- Expand native Proxmox backup job management (schedule, compression, retention, guest selection, notifications)
- Add ru/en translations for the above
Watchdog rebuilt images with --no-cache on every push, writing fresh
build-cache layers that were never reused. Over ~2 weeks this grew the
Docker build cache to 57GB and filled the production disk.
- Switch `build --no-cache` to `build --pull` (cacheable). Dockerfiles
already isolate heavy layers (apt/pip/npm) from source COPY, so app/
frontend changes are still rebuilt — without re-running apt/pip/npm.
- Add `docker image prune` + `docker builder prune until=24h` after a
successful deploy so old images and stale cache don't accumulate.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The host watchdog ran `down` before `build --no-cache`, so a failed
build left the whole stack offline ("code updated, containers don't come
up"). Reorder to build first (app + frontend) while the old stack runs;
only tear down once images are ready. Use `up -d --wait` so success means
containers actually became healthy (DB migrations run on app startup),
and log `compose ps` + a hint on failure.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Root cause: docker compose down killed the nohup script inside the
container before rebuild could complete — only git pull was visible
(updated VERSION file).
Changes:
- update_host.sh: new host-side watchdog (poll .update_trigger every 3s)
runs: git pull → docker compose down → build --no-cache app → up -d
PROJECT_DIR and User are dynamic (set at install time, not hardcoded)
- update_service.py: perform_update() now writes .update_trigger instead
of running git/docker commands inside the container
- deploy.sh: added install_update_watchdog() + --watchdog CLI option;
generates /etc/systemd/system/pvemanager-update.service dynamically
with correct User= and WorkingDirectory= for any install path/user
- .gitignore: ignore .update_trigger and generated systemd/ files
- CHANGELOG, VERSION, WIKI: bump to v1.1.1, document new update flow
