- its log;
- the Runners section on the factory’s Settings, General page;
- an email from OuterLayer;
- a Work page item that reads “runner needs an update”.
Run the update
How a runner updates depends on where the runner itself runs. It does not depend on where its builds run. A runner whose builds run in containers and one whose builds run in microVMs update the same way when they run in the same place. Find how you started the runner, then run the commands for it.
The commands install the newest release. If the factory’s Runner updates setting is Hold at a version, put that version in place of
latest.
The runner image
Pull the new image, then replace the container with one made from it. Keep the same volume. First, print the mounts of the running container. The new container needs the same ones::/root/.outerlayer is the runner’s own state: its config and its host key. It is outerlayer-runner:/root/.outerlayer if you started the runner with these docs. If it names a folder, such as /Users/you/outerlayer-runner:/root/.outerlayer, use that folder in place of outerlayer-runner below. A new or different mount starts an empty runner, and the factory refuses its runner key.
If you already removed the old container, its state is still on disk, in the volume or folder that holds config.json and runner/host-key.pem. If none holds them, start with an empty mount. The factory then refuses the runner key, because the key is bound to the old host key. Do one of these:
- In Settings → API keys, select the clear host key icon, a crossed-out link, on the runner key’s row. The icon shows only on a key that a host has used.
- Create a new runner key and put it in your env file. A new key is bound to no host.
docker pulldownloads the new image.docker stopanddocker rmremove the old container. It still runs the old image.docker runstarts a new container from the new image, with the mounts you printed and the same--env-file.
outerlayer command on the machine itself is a separate copy: update it with npm install -g @outerlayer/cli@latest.
The volume holds the runner’s config and its host key, so the new container is the same runner. Builds survive the change. A container never moves to a newer image by itself, even when it restarts. Docker reads the latest tag only when you pull.
A service runner
A service runner updates itself unlessrunner.autoUpdate is false. To update it by hand:
outerlayer launcher in ~/.local/bin still runs the old version. Do not restart the service: it restarts on the new version once its running builds allow it. For a runner with your own hooks, leave out --service.
A runner in a Lima VM on a Mac
The runner in the VM updates itself. To update it by hand, open a shell in the VM:A runner started in a terminal
A runner started in a terminal never updates itself.outerlayer runner install --service in place of outerlayer runner start. The runner then runs as a service and updates itself from then on.
Check that it worked
- Run
outerlayer --versionwhere the runner runs. For the runner image, rundocker exec outerlayer-runner outerlayer --version. It prints the new version. - Run
outerlayer doctorin the same place. It reports no failure. - Open the factory’s Settings, General page. The Runners section shows the runner as Ready, at the new version.
outerlayer doctor says the microVM helper needs reinstalling, run outerlayer runner install --service --replace. See Update the microVM helper.