Update or redeploy dotMARC
The newest release is 0.7.1. See Releases and Updates for what changed in it and in earlier versions.
Before you update
- Read the release notes for every version you are skipping. Each one has an Upgrading section that says whether anything needs your attention, such as a new permission or setting.
- Your data is kept. Reports, settings and secrets live in PostgreSQL, so an update replaces only the
application. Never remove the database volume, and never add
--volumestodocker compose down. - Migrations run by themselves when the new version starts. An older version isn't always compatible with a newer database, so take a PostgreSQL backup first if you might need to roll back.
- Prefer a release tag to
:latestin production. A tag such as:0.7.1says exactly what is running and what to go back to.:latestmoves under you and needs an extra step to pick up a new build.
Choose how you run dotMARC
| How you run dotMARC | Go to |
|---|---|
Docker Compose, using the supplied docker-compose.yml files | Rebuild from the repository |
| Docker Compose, using your own file with the published image | Custom Compose file using the published image |
Docker, with the image tagged :latest | If the image is tagged :latest |
Docker, with a plain docker run | Standalone docker run |
| Azure Container Apps | Update to a specific release |
Azure, with the image tagged :latest | Redeploy when the app is configured with :latest |
| Azure, managed through the Bicep template | Update through Bicep |
Check it worked
- Open dotMARC and look at the version in the footer. It links to that release's notes.
- Check Manage > Server logs for new warnings or errors. See Server logs.
- On Azure, follow Verify the update to confirm the new revision is healthy and taking traffic.
Roll back
Go back to the previous release tag and recreate the application, the same way you updated. The detailed steps, including the database caveat, are in Docker: Roll back and Azure: Roll back. Don't roll back blindly after a release that applied database migrations, because the older version has to work with the schema the newer one left behind.