Upgrading¶
install.sh is idempotent. To upgrade to the latest main, re-run it on the host:
What re-running does:
- Fast-forwards the cloned repo at
${NOVA_VE_REPO_DIR}(default~${SUDO_USER}/nova-ve-git). - Re-runs
provision-ubuntu-2604.shto top up OS-level packages. - Reapplies the backend venv (
pip install -r requirements.txt) and Alembic migrations. - Rebuilds the frontend (
npm ci && vite build) and rsyncs it into/var/lib/nova-ve/www. - Restarts
nova-ve-backendandcaddy.
It does not rotate existing secrets, drop the database, or touch lab JSON files. The smoke check at the end exits non-zero if anything broke.
Pinning to a specific release¶
Set NOVA_VE_REPO_REF before piping the installer:
NOVA_VE_REPO_REF accepts a branch, tag, or SHA.
Manual upgrade (without the installer)¶
If you prefer to drive the upgrade yourself:
cd ~ubuntu/nova-ve-git
git fetch origin
git checkout v0.4.0 # or main, or a specific SHA
# Backend
cd backend
.venv/bin/pip install -r requirements.txt
.venv/bin/alembic upgrade head
# Frontend
cd ../frontend
npm ci
npm run build
sudo rsync -a --delete build/ /var/lib/nova-ve/www/
# Restart
sudo systemctl restart nova-ve-backend
The Caddy unit reloads itself on file changes and does not need restarting after a frontend rebuild.
What can go wrong¶
- Alembic migration fails — investigate with
journalctl -u nova-ve-backend -n 100. Common cause: out-of-order migration heads after a long detour. The contract is thatnova-ve-backenddoes not self-migrate; you mustalembic upgrade headmanually before restarting. - Frontend build fails — usually a Node version drift. The provisioner installs Node 22.x from NodeSource; if you bumped Node manually, ensure it still satisfies
package.json'senginesfield. - Caddy refuses to start — port 80 / 443 already in use.
sudo ss -ltnp | grep -E ':(80|443) 'finds the offender.
When in doubt, Troubleshooting has the recipes.