Updates (health-gated, with rollback)

stack deploy applies whatever is there. stack update decides whether to, and undoes it if the result is not healthy:

baryovm stack set-update barako --health-url http://127.0.0.1:5005/health --auto
baryovm stack set-update baryoclub --health-url http://127.0.0.1:8091/health --no-auto

baryovm stack update barako --dry-run   # report what is pending, change nothing
baryovm stack update barako             # apply, verify, roll back if it does not come up
baryovm stack update barako --auto      # what a scheduler runs

What it does: pull, compare each container against what its reference now points at, and stop if nothing is stale. An unchanged stack is never recreated, so a nightly job is not a nightly restart. When something is stale it backs up the database, recreates only the affected services, and polls the health URL from the VM. If health does not come back, it points the references at the images that were running before and brings those back up, then checks again and says which of the two states it ended in.

--auto refuses four things, all for the same reason: an unattended update has to be able to tell a healthy start from a crash loop, and to go back when it cannot. It refuses a stack without autoUpdate, a stack without a healthUrl, the flag combination --auto --no-backup, and a stack with no database backup configured at all. Set autoUpdate on the tiers you are willing to have change unattended: playground, not production.

A stack that genuinely has no database says so once, and keeps updating:

baryovm stack set-update barako --no-database

That is a recorded decision rather than a silent gap. The refusal exists because a stack with no dbContainer and no dbName used to skip the backup entirely and run unattended anyway, which is what the other three refusals exist to prevent. A --dry-run is exempt from both backup refusals, since it recreates nothing and so has nothing to go back from.

Run it from cron on the VM, or from anywhere with SSH access:

0 4 * * * /usr/local/bin/baryovm stack update barako --auto -o json >> ~/baryovm-update.log 2>&1

Verified against a stack whose image was swapped for one that exits on start: the update was applied, the health check failed, the previous image was restored and the site was serving again, and separately, that a genuine new image is kept when it comes up healthy.