Documentation / Operations
Upgrades
Signed bundles, ordered migrations, and a version that refuses to skip.
How a release ships
A single signed archive containing the container images, the migrations, the release notes and a checksum. Nothing is fetched during an upgrade — the bundle is complete.
Every release carries its declared predecessor. A bundle that does not follow your installed version is refused rather than applied, because migrations are ordered and applying them out of sequence produces a schema nobody designed.
Upgrading
Verify
Check the bundle checksum against the published value before anything else.
Back up
dg backup create --out ./pre-upgrade. Take it even for a patch release.
Apply
dg update apply ./dg-2026.08.bundle. Signature checked, predecessor checked, images loaded, migrations run in order, each reported.
Verify again
dg health. Every service, the database, the model endpoint and the collectors — anything unreachable is named.
Migrations
Each is proven reversible before it ships — applied, rolled back, and applied again. If one fails during an upgrade the platform stops at that migration and reports it rather than continuing.
It does not partially apply and carry on. A schema half-migrated is worse than a schema not migrated, and the difference is only visible later.
Rolling back
Restore the pre-upgrade backup and reinstate the previous images. Because migrations are reversible and the backup includes the schema, a rollback returns you to a known state rather than an approximate one.
Release notes
Every bundle carries them, and they name what changed, what was fixed, and what is known not to work. A release note listing only improvements is a release note telling you half the story.
Not running it yet? Start a thirty-day evaluation — read-only, on your own estate, no card.
Thirty days · read-only · no card
Run it beside what you already have, against your real clients. It tells you what your tools are reporting that is not true.