How licensing, Call-Home, updates and rollback work — and why your data is safe through all of it.
d0pe verifies a cryptographically signed license bound to your hardware id. A small heartbeat (no lead data) keeps feature flags current and detects cloned VPS snapshots.
When a new signed version is published, the Owner sees an “Update available” banner in the CRM. One click on “Update now” pins the new version, pulls the signed image and rolls api / worker / beat / web; database migrations run automatically on first boot. Nothing is ever built on your box — you only pull a pre-built, signed image. Prefer the shell? Bump CRM_VERSION in .env and docker compose up -d, or run ./update.sh.
An update — or a rollback — swaps the app image only. Your database, analytics and files live in Docker volumes that the update leaves alone, so Postgres comes back on the same volume with every lead, flow and status intact. It's an image swap over the same data, not a reinstall. As a habit, still take a database snapshot before a major update (see Backup & restore).
Rollback is the same mechanism in reverse: pick any earlier published version from the update panel, or run ./rollback.sh <version>, and the app rolls to it on the same data. Because it just re-pulls an older image over the untouched volumes, no leads are lost.
A network blip or short outage never affects you — a generous grace window (72h by default) keeps the instance fully working. Only a definitive expired or suspended verdict past grace switches the CRM to read-only: your data stays intact and you can still view and export everything, new writes pause until you renew, and the instance returns to normal on the next heartbeat after renewal.