Upgrading SpeedyFiles

SpeedyFiles auto-migrates its database on startup. Most upgrades are docker compose pull && docker compose up -d with no further action.

Always: back up first

See Backup & restore. At minimum:

sqlite3 /data/app.db ".backup /data/app.db.pre-upgrade"

Docker

cd /path/to/your/speedyfiles
docker compose pull            # fetch the new image
docker compose up -d           # recreate the container with the new image
docker compose logs -f         # watch startup

Bare-metal

cd /opt/speedyfiles
sudo systemctl stop speedyfiles
sudo -u speedyfiles git pull
sudo -u speedyfiles .venv/bin/pip install -r requirements.txt
sudo systemctl start speedyfiles
sudo journalctl -u speedyfiles -f

Database migrations

SpeedyFiles uses idempotent in-process schema bumps for the small set of changes that have shipped to date. Each startup:

  1. Sets WAL mode, foreign-key enforcement, etc.
  2. Runs Base.metadata.create_all — creates any missing tables
  3. Runs additive column-ALTERs for columns that didn't exist in earlier versions

No down migrations are supported. If a release introduces a breaking schema change, the release notes will spell out the required steps.

Pinning to a specific version

# docker-compose.yml
services:
  speedyfiles:
    image: ghcr.io/bokelleher/speedyfiles:v0.1.0   # pin to a tag
    # …

Rollback

If an upgrade goes sideways:

docker compose down
docker pull ghcr.io/bokelleher/speedyfiles:v0.1.0   # whichever was previous
# Edit docker-compose.yml to pin: image: ghcr.io/bokelleher/speedyfiles:v0.1.0
# Restore DB from pre-upgrade backup
cp /data/app.db.pre-upgrade /data/app.db
docker compose up -d

Release channels

TagWhen to use
latestProduction single-instance lab/internal use; tracks main
vX.Y.ZProduction where you want explicit upgrade control
mainDevelopment; rebuilt on every push to main
pr-NNNOpen pull-request builds, for QA

Reading the changelog

Always skim CHANGELOG.md between versions for: