Updating

blysis update

It pulls the newest image, applies any migrations the release carries, rebuilds if the module set needs it, and restarts. On a small site it takes under a minute; the site answers the whole time except for the restart.

Update the platform before the modules

A module declares which core API versions it works against, as a range. Core refuses to enable a module the running core cannot satisfy rather than letting it fail later at runtime, so a platform that is behind can block a module update that is ahead. Updating in that order means the range is already satisfied when the module arrives.

What a release can change

Additions are the common case. A new symbol in the SDK, a new optional block in the manifest. Nothing that worked stops working, and the core API version gains a minor.

Breaks gain a major, and that is exactly what a module's declared range is for: a module built against the old shape refuses to enable rather than rendering a broken page. The release notes say what moved.

Read the notes before a major. blysis update will not stop you, but a module you depend on may not have caught up yet.

Back up first

blysis backup
blysis update

Two commands, in that order, every time. A migration is forward only and deliberately so: rolling one back guesses at data it cannot see. The backup is the way back, and it is worth ten seconds.

When an update goes wrong

The previous build is still on disk and is still what gets served if the new one fails. So the failure mode is usually "the site is up and running the old version", not "the site is down".

blysis logs       # what the build said before it stopped
blysis status     # what is running, and since when
blysis restart    # after fixing whatever it named

If a module is the cause, disable it from the admin panel and the next build leaves it out. If the panel is not reachable, blysis restore puts the backup back, database and uploads together.