Why updates hurt elsewhere
With most content systems, updating is when things break — so people postpone updates, and postponed updates are how sites get compromised. Loam is built so that an update is not an event: routine, small, and undone by itself when it goes wrong.
The engine is one folder, your site another
Content, templates, images and keys live in their own folders, and an update never touches them. It can change what the engine renders from your data; it cannot change your data. No plugins to fall out of step, no database to migrate — and the site's configuration describes the site, not the engine, so a newer engine reads the same file.
Whole parts, never loose files
The engine is made of five members — core, docs, edit, setup and shell. An update swaps a member as a whole, because a member is tested as a whole. You can take all five, or only the ones you need; members that must speak the same version move together, or nothing moves at all.
Signed releases
loam update takes only a release signed by loam, checked against the trust anchor your site holds — an anchor no release can replace. The download is checked against its checksum before it is unpacked. A tarball that does not verify is never opened.
It checks its own work
Right before the swap, the old engine renders a handful of your pages — the home page, each language, one page per type. Right after, the new engine renders the same pages again. If a page that worked stops working, the update undoes itself on the spot and names the page. A page that was already broken is reported, but never blocks. Either way, a line lands in the site's journal.
Someone chooses the moment
An update never runs by itself. It is one command on the server, chosen by a person: Braaf runs it on the sites it maintains, and on your own server you run the same command. What loam removes is the cost of updating, so keeping current is routine instead of a project.