Automatic builds

A watch keeps your demos current without you doing manual builds after each release. It follows a release feed and when a new version appears we rebuild the VM from its recipe and publish the result. The share link and every embed of it start serving the new machine.

Watches are part of the paid and open-source plans.

Set up a rebuild on every GitHub release

Say your app is acme/widget on GitHub, and each release publishes an arm64 Linux binary.

1. Add the watch

On the VM's page, open Version watches and fill in the form:

Field	Value	Notes
Name	widget	Becomes the placeholder name {{versions.widget}} to be used in the build recipe. Lowercase, and it cannot be changed later.
Source	GitHub release	The other option is Docker / GHCR tag.
Target	acme/widget	owner/repo.
Tag filter	v*	Optional glob. Leave it blank to accept every release.

Press Add watch. Adding a watch never triggers a rebuild by itself, only a change does.

2. Use the version in your recipe

The watch's name is a placeholder your commands can use:

apk add curl
curl -fLo /usr/local/bin/widget \
  https://github.com/acme/widget/releases/download/{{versions.widget}}/widget-linux-arm64
chmod +x /usr/local/bin/widget

A placeholder is optional

A watch with no placeholder anywhere still triggers a rebuild on a new release. Useful for example when your install command already fetches the latest version by itself like apk add widget, etc.

3. Save and build once

Press Save recipe, then ▶ Build to check that the recipe works with a real version filled in. From then on it is automatic.

Watching a Docker tag

Same form, with Source set to Docker / GHCR tag:

Field	Value
Target	acme/widget, or ghcr.io/acme/widget
Tag filter	v*, *-stable, …

A target starting with ghcr.io/ goes to the GitHub container registry. Anything else goes to Docker Hub.

How an automatic rebuild works

1. We check the feeds about once an hour. GitHub pre-releases are ignored. The tag filter is applied, and versions are compared the way version numbers sort, so 1.10.0 is newer than 1.9.0.
2. A new version queues a rebuild. Each VM rebuilds at most once a day using the latest available version.
3. The build runs on our servers. It is the same build the studio runs just ran by us.
4. On success, the live demo is updated.
5. If the VM has a guide, we replay it against the machine we just published and email you the per-step result.
6. On failure, the live demo is untouched and you get an email with the build log. Your visitors keep seeing the last version that worked, not a broken one.

Managing watches

• Disable leaves a watch in place but stops checking it. Remove deletes it.
• A watch's name cannot be changed, because recipes refer to it.
• Removing a watch that a recipe still refers to leaves a recipe that cannot be saved.

When it does not fire

What you see	Usual cause
Nothing happens after the release	The release is a pre-release (ignored), or the tag does not match the filter.
The rebuild is late	Feeds are read about once an hour, and a VM builds at most once a day.
The build failed	Read the emailed log. The usual cause is an install command that no longer works with the new version — the same failure you would get running it by hand.
{{versions.x}} is not replaced	There is no watch named x on this VM. The names must match exactly.

Next

• Create a VM — the recipe the rebuild replays.
• Create a guide — and the automatic check that runs after each build.