# 8. Updating and rolling back

Alloy publishes no images, so there is nothing for your machine to download.
Updating means rebuilding the image on a machine you own and switching to it.
Rolling back means picking last boot's deployment from the boot menu.

## What your machine is running

    alloy update

shows the deployments: which image is booted, which is staged for the next
boot, and what can be rolled back to. It fronts `rpm-ostree status`, so the
same information is available as:

    rpm-ostree status

Deployments are the whole model. Nothing is ever edited in place. An update,
a layered package, and a rollback all produce or select a deployment, and the
switch happens at boot.

## Updating

On the machine where you keep the source:

    cd alloy
    git pull
    build/build-iso.sh --skip-source     # or build/build-image.sh

Either one rebuilds `localhost/alloy:local`. Then, on the machine to update:

    bootc switch --transport containers-storage localhost/alloy:local
    systemctl reboot

That adopts the locally built image in place. It is staged with A/B rollback,
exactly like a registry-fed update would be, with the image coming from local
container storage instead of the network.

You do not reinstall. Your home directory, your accounts, and your layered
packages survive. What you give up against a published image is the build time,
not the machine.

If the build happened somewhere else, move the image the way you would move any
container image (`podman save` / `podman load`, or a local registry) and switch
against that.

## Rolling back

If a new image is worse:

    rpm-ostree rollback
    systemctl reboot

The previous deployment is still on disk, so this is fast and does not need a
network. It swaps which deployment boots by default.

You can also do it without booting the broken image at all: hold `Esc` or
`Shift` at boot to get the GRUB menu, and pick the older entry. That boots it
once. If the older one is the one you want to keep, run `rpm-ostree rollback`
from it.

## Why nothing updates itself

An installed machine does not poll for updates. The timer that would do it is
enabled only when the installer medium named an update target, which only a
development build does.

The consequence worth stating: **an image built in January and run until June
carries January's packages**, including the browser, which is the program on
your machine that faces the whole internet all day. If you run Alloy as a daily
driver, rebuild on a rhythm you decide rather than when something breaks.

`alloy update` reporting how far behind the image has fallen, with the browser
called out rather than buried in a package count, is filed work and not yet
shipped. Until it is, the honest answer is that the date of your last rebuild
is the number that matters, and only you know it.

## What about `bootc upgrade`

It works, and does nothing useful here: there is no registry for it to fetch
from unless you set one up yourself. If you run your own registry, point the
build at it with `build/build-iso.sh --update-target <registry>/alloy:43` and
the installed machines will use the standard bootc update path.