Upgrade

Standard sequence: backup → upgrade → migrate → doctor → rollback/restore on failure. Supported: current version → next version.

Steps

cd /opt/siroping
git pull                                # or replace the release
./venv/bin/pip install -r requirements.txt

# 1) Preflight — refuses to run if disk is low or backup is stale
python manage.py upgrade_check

# 2) Upgrade — mandatory backup -> migrate -> collectstatic -> check -> doctor
python manage.py upgrade

# 3) Restart the three services
sudo systemctl restart siroping-web siroping-worker siroping-beat

# 4) Verify
python manage.py doctor                 # Overall: HEALTHY

When the upgrade fails

manage.py upgrade reports which step failed and the path of the pre-upgrade backup. There is no blind auto-rollback (code + schema rollback isn't always safe):

sudo systemctl stop siroping-web siroping-worker siroping-beat
python manage.py restore /path/to/pre-upgrade-backup --yes
python manage.py migrate
sudo systemctl start siroping-web siroping-worker siroping-beat
python manage.py doctor

Preflight rejection

upgrade refuses to run if:

• Disk free < 0.5 GB
• No previous backup, or the last backup is older than 96h

Moving between servers ≠ upgrade

Moving a customer from the demo to their own server is migration, not an upgrade — see Migration.