My redeploy cancelled the build my change started

You ran lizard service set to change a field, then lizard redeploy. The deploy took longer than expected, and the history may show a cancelled build.

What this means

The service set call already started a rebuild on its own. The follow-up redeploy cancelled that build, whose log ends with --- Build cancelled: a newer deploy was triggered ---, and started the same build again from the beginning.

Why this can happen

Changing a build-affecting field on a service — repoUrl, branch, sourceType, buildCommand, dockerfilePath, or rootDirectory — auto-rebuilds a running service immediately. A crashed or never-deployed service does not rebuild on its own. Changing a runtime-only field — startCommand, preDeployCommand, containerPort, watchPatterns — does not auto-rebuild; it takes effect only on the next deploy.

It’s easy to reflexively chain a redeploy after every service set, but that only makes sense for the runtime-only fields.

Possible solutions

Check which kind of field you changed

See the rebuild triggers table. If it’s a build field and the service was running, the rebuild has already started — do nothing further. If the service was crashed or never deployed, run lizard redeploy once.

lizard events   # is a build already running?

Only redeploy after runtime-only changes

lizard service set api --set startCommand="node server.js"
lizard redeploy --service api   # needed here — startCommand doesn't auto-rebuild