Upgrades and health checks
Check, apply and roll back a named Dexta release, and point an uptime monitor at each app.
Updated 15 October 2026
What you’ll do: move your server to a new Dexta release safely, and keep an eye on it.
Who can do this: your IT team, with shell access to the Dexta server.
Upgrading
- See what you’re running now with
./deploy/versions.sh. - Check the new release first:
./deploy/upgrade.sh --check v1.40.0(use the release name we send you). It changes nothing. - Upgrade:
./deploy/upgrade.sh v1.40.0. It takes a database dump just before it starts. - Open the Hub and a couple of apps and check they work.
- If something is wrong, run
./deploy/upgrade.sh --rollback. This goes back to the dump taken before the upgrade, so anything entered since is lost: decide quickly.
Health checks
- Each app answers
/version.jsonand/api/v1/health(and/api/v1/health/dbfor its database). Point your uptime monitor at these. - Patch the operating system and the containers monthly. The guide’s
./deploy/build.sh --pullfetches the latest base images. - With public names, certificates renew by themselves. If you use your own certificate, check its expiry date before it runs out.
Good to know
- To switch an app on for a company, Dexta’s operator uses App entitlements in the Hub.
- Day-to-day logs:
dc logs --tail 100and the service name.