Upgrades and support

An upgrade changes the image and may apply database migrations. Read the exact release's notes before starting and preserve a recovery point that belongs to the previous version.

Supported release

Support covers the latest promoted supported release. Fixes, including security fixes, are delivered in a new release. There is no implied maintenance period or backport promise for an older version. A private candidate or unpromoted tag does not become supported because a guide describes it. This page does not announce an available release.

The accepted Business offer includes bounded standard email support for installation, upgrades, running the documented default topology and defects. It includes no uptime or response-time promise. Custom infrastructure, migrations and integrations are scoped separately. This policy does not open purchasing or change an existing agreement.

Use the support contact whose delivery has been confirmed for your installation. Private vulnerability reporting uses the established security contact; it is separate from commercial support eligibility.

Prepare and upgrade

1. Obtain the promoted version's immutable website record and read its notes and frozen guidance. Verify the files and image as described in installation.
2. Take a database-consistent backup and retain the credential-sealing key and required protected configuration. Restrict backup access. An application export is not a complete credential or installation backup; it deliberately leaves out some sensitive state.
3. Confirm the notes' migration and rollback conditions. Do not assume an older image can read a newer schema merely because an earlier upgrade was additive.
4. Set LOGMARQ_IMAGE to the new record's exact digest, then run docker compose pull and docker compose up -d.
5. Check /api/health, sign in and inspect representative projects, release records and configured integrations. Retain the previous backup until these checks pass.

Recover a failed upgrade

Keep the failed installation and logs available for diagnosis. Stop writes before restoring. Follow the exact release's recovery procedure in an isolated copy first. Roll back the image alone only when that release explicitly documents schema compatibility; otherwise restore the matching database, key and configuration before starting the earlier image. Do not delete the only data volume while attempting recovery.

An import preserves the historical records supported by its snapshot format; it is not evidence that provider credentials, sessions or licenses were restored. Reconfigure and verify each excluded item through its existing protected flow. See troubleshooting for the small, redacted report to retain.