embabel upgrade [--release <release>] [--allow-downgrade]

Onto the newest published build of the release this appliance follows — the checkout and the images. Your data is untouched — this is the opposite of up --fresh. --release moves the appliance to another release first, exactly as embabel release <release> does.

Both halves, because for a long time this moved only the images while the Me app’s menu moved both, and the two doors meant different things by the same word. setup.py owns it now, so they cannot drift again.

• --ff-only, always. A dirty or diverged checkout is reported and left alone; the images still update. It names what changed, and tells you to run npm --prefix me-app run build when the pull touched me-app/, since nothing in the run path rebuilds dist/.
• It verifies. The image digest is read before and after, then the container’s actual image id is checked — “pulled” and “the container is running it” are different claims.
• The guides follow. The appliance keeps its own documentation indexed in your world: it reads guides.json from the repository this checkout follows when it starts and once a day after, indexes guides that are new or changed, and removes ones that were withdrawn. It only ever removes documents it put there, so nothing you added is touched. No command, and no password.
• It builds nothing. The compose files are pull-only by design.
• It never steps back without being told. The target is pulled and compared with the running build before anything is recreated: by release number when both are X.Y.Z, by build time (org.opencontainers.image.created) otherwise. An older target stops here with both builds named — the running server stays, and .env still says what it said. --allow-downgrade goes ahead; take embabel backup first, because an older server may not read what a newer one wrote.