CS EN

Updating LockMyCal to a New Version

LockMyCal is designed so that updates run quickly, reliably and with minimal downtime. All Ecto database migrations run fully automatically at every start of the new container.

Step-by-step update procedure (Docker Compose)

1. Create a safety backup of the database

Before every update, we recommend creating a quick backup:

docker exec -t lockmycal-db pg_dump -U lockmycal lockmycal_prod > pre_upgrade_backup.sql

2. Build the new version

In docker-compose.yml (or in the LOCKMYCAL_VERSION variable), set the new version tag in build.context and build the image:

docker compose build --pull app

3. Restart the containers with the new image

docker compose up -d --remove-orphans

Docker automatically replaces the old container with the new version. At startup, LockMyCal checks the database schema, performs the necessary migrations and restores the real-time connection.

4. Verify the health of the instance

Check the startup logs:

docker compose logs -f app

You should see a message confirming the successful start of the HTTP and WebSocket server on port 4000.

Database and calendar event changes (1.20.0.1)

Updating to 1.20.0.1 adds database migrations that run by themselves at startup (so don't skip the backup from step 1):

  • new tables error_tracker_* (error tracking) and admin_alert_digest_entries (the daily alert digest),
  • new columns meetings.calendar_uid, meetings.organizer_note and meeting_guests.invited_by.

The event LockMyCal writes to a connected calendar now carries its own UID instead of the booking's UID (the cancel and reschedule links are built from the latter, so this is safer). Meetings created earlier keep their original event UID.

Returning to the previous version (Rollback)

If an unexpected incompatibility appears after an update, you can return to a specific previous tag at any time:

  1. In docker-compose.yml, change the version in build.context back to the previous tag.
  2. Run docker compose up -d --build.
  3. In the case of irreversible database changes, restore the DB from the backup created in step 1.

Changes that break compatibility

Before updating across these versions, check your configuration:

  • 1.11.1 – The headers of outgoing webhooks were renamed from X-Tymeslot-* to X-Lockmycal-* (X-Lockmycal-Token, X-Lockmycal-Timestamp) and the User-Agent to Lockmycal-Webhooks/1.0. Adjust the header check on the recipient's side.
  • 1.15.7 – The .env file is read literally: ${VAR} and $(command) are not expanded, and a # without a space before it is part of the value. Write out in full any values that relied on interpolation.
  • 1.16.0 – Zoom meetings are moved when rescheduling; the Zoom application needs the meeting:update:meeting permission, otherwise set ZOOM_UPDATE_SCOPE_ENABLED=false.
  • 1.20.0.1 – The delivery ID header of outgoing webhooks was renamed from X-Tymeslot-Delivery-Id to X-Lockmycal-Delivery-Id; the old header is no longer sent, and the value (the delivery ID) stays the same. If you de-duplicate deliveries by it on the receiving side, update the header name.