Upgrading
Upgrading a compose-stack deployment is a rebuild:
git pulldocker compose up --build -dWhat survives an upgrade
Section titled “What survives an upgrade”- Your data. MongoDB and MinIO live in named volumes (
mongo-data,minio-data); rebuilding images doesn’t touch them.docker compose down -vdoes — the-vdeletes volumes, so avoid it unless you mean it. - In-flight respondents. Responses are pinned to the questionnaire version they started on, and published versions are immutable — an upgrade (like a publish) never changes what an in-progress respondent sees.
- Definitions across schema changes. The questionnaire definition
carries a
schemaVersion; the backend currently accepts versions 1 and 2, and the editor migrates a draft forward the next time it saves.
What to check after upgrading
Section titled “What to check after upgrading”- The backend starts — the storage canary runs at every boot, so a storage regression fails loudly rather than quietly.
- If you pinned an embed bundle (self-hosted copy of
forms-engine.esm.js), rebuild or re-copy it so the embed and backend stay in step.
Moving questionnaires between environments
Section titled “Moving questionnaires between environments”Use export/import rather than copying database documents: Export on the questionnaire list downloads a portable JSON file (the draft definition, name, and an envelope version); Import on the target creates a new questionnaire from it with a fresh public id and empty origin list, and validates it at full publish strictness before anything is created. Responses and version history deliberately don’t travel with it. See Export & import.
There is no downgrade path
Section titled “There is no downgrade path”Version documents and responses written by a newer backend aren’t guaranteed readable by an older one. Back up the Mongo volume before major upgrades if you need a way back:
docker compose exec mongo mongodump --db forms_engine --archive > backup.archive