Skip to main content

​
Overview

CaseBender ships as a set of versioned container images. Upgrading means pulling the latest images and recreating the containers. Your data, license, and configuration live in named Docker volumes and your .env file — both are preserved across upgrades, so an upgrade never touches your cases, users, credentials, or license as long as you keep them.
Database migrations and default-data seeding run automatically on startup after every upgrade. You do not need to run any migration commands manually.

​
What persists across upgrades

Never run docker compose down -v on a production system. The -v flag deletes all named volumes — your database, license, and files. Without those volumes, the next start creates a fresh database, which resets the admin password to the default and regenerates the license.

​
Upgrade procedure (Docker Compose)

1

Back up your database and .env

2

Pull the latest images

3

Recreate the containers

Compose recreates only the services whose image changed and keeps your volumes.
4

Watch the logs

Migrations and seeding run on boot — wait for the app to report healthy.

​
Verify after upgrading

  • Sign in and confirm your existing cases, alerts, and users are present.
  • Confirm your login still works (your admin password is unchanged).
  • Check the worker is processing jobs:

​
Rollback

If something goes wrong, pin the previous image tag and restore your backup:
Always upgrade a staging environment first, and take a fresh database backup immediately before upgrading production.

​
Common upgrade mistakes

The two most common problems both come from losing state:
  • Changing the Compose project name or directory. Docker derives volume names from the project. Renaming the folder or using a different -p project name points Compose at new, empty volumes. Always upgrade from the same directory/project so your existing volumes are reused.
  • Missing LICENSE_SECRET_KEY and no casebender_secret volume. On older deployments without the persistent secret volume, set LICENSE_SECRET_KEY in .env (or add the volume) so the license survives. Current deployments persist it automatically.

​
Desktop Installer

If you deployed with the Desktop Installer, use the app’s built-in update flow — it pulls the latest images and recreates services while preserving your data directory, .env, and license key.

​
Google Cloud Run

Cloud Run upgrades deploy a new revision. Because Cloud Run has an ephemeral filesystem, the license secret must be provided via Secret Manager as LICENSE_SECRET_KEY so it persists across revisions. Redeploy against your existing Cloud SQL instance and secrets:
Migrations run automatically on the new revision.