Upgrading

Back up your ledger and retain deployment settings before updating an existing installation, then verify the result.

Upgrading doesn’t require touching your data. Schema changes ship as migration files with the code and run automatically on deploy; old records and old backup formats keep working.

Export a full backup under Settings → Data → Export full backup before upgrading, just in case.

1. Export a full backup and record the current version, volume and environment variables.
2. Update the code or image below, retaining domains, secrets and persistent storage settings.
3. Sign in, check subscriptions, Wallet and notification channels, and test enabled integrations such as MCP or the calendar feed.

Cloudflare

If you deployed from the command line:

cd calends
git pull
npm ci
npm run deploy

npm run deploy applies new migrations to the remote database after deploying. Even if that step were skipped, the Worker fills in missing migrations on its first request.

If you used one-click deploy, the repository lives in your own GitHub account. Sync it with upstream imetn/calends (Sync fork on GitHub, or merge manually) and Cloudflare rebuilds and deploys from your repository.

If you’ve edited wrangler.jsonc (custom domain, email binding), keep those changes when you pull.

Docker

docker pull ghcr.io/imetn/calends:latest
docker stop calends
docker rm calends
docker run -d --name calends --restart unless-stopped \
  -p 8787:8787 -v calends-data:/data \
  ghcr.io/imetn/calends:latest

With compose:

docker compose pull
docker compose up -d

The docker run above is a minimal example. Reapply your original SITE_URL, TRUST_PROXY, SETUP_TOKEN, ports and other environment variables, and use the same data volume name.

Data lives in the volume, so removing the container loses nothing. The new container applies migrations before starting.

To pin a version and upgrade on your own schedule, use a version tag instead of latest, such as ghcr.io/imetn/calends:1.0.

Rolling back

Switching back to old code does not undo database migrations. Check that the old version can read the current schema before rolling back; a successful start alone does not prove compatibility.

If you need to restore data, keep a copy of the current database and restore the pre-upgrade backup on a compatible version. Do not give your only migrated database to an older version whose compatibility is unknown.