Execution Backends

An execution backend is where a run’s work actually happens. Wayland Core defines one provider-neutral contract for that and ships four reference implementations against it.

wayland-core backend

Execution backends landed in v0.12.26.

The four reference backends

Backend	Runs work
local	On this machine
ssh	On a host you can reach over SSH
container	Inside a container
cloud	On a machine the backend creates for the run

The contract is the point. A backend is a seam, so a run does not need to know which of these it landed on, and adding a fifth does not mean touching the loop that dispatched the work.

The cloud backend really does the thing

It is worth being precise here, because “cloud backend” is a phrase that often means less than it sounds like. This one creates, runs, and hibernates a machine. It is not a queue that eventually reaches a box somebody else provisioned.

A cancelled run writes a Cancelled receipt rather than vanishing. That distinction matters when you are reconciling spend or asking why a Goal has no output: a cancelled run is a fact you can find, not an absence you have to infer.

Attribution and orphans

Nodes carry attested attribution, so what ran where is recorded rather than assumed.

An orphan scanner sweeps what got left behind. Any system that creates machines will sometimes fail to clean one up, and a scanner that finds them is the difference between a bounded bill and an unbounded one.

Verifying against the backend

wayland-core receipt verify --against-backend

This checks identity, not just integrity. Integrity alone tells you a receipt was not tampered with. Identity tells you the receipt belongs to the node that actually ran the work, which is the question you care about when you are deciding whether to trust a result.

See also Budget and Cost Caps for the spend side of remote execution, and Durable Goals for the intent that survives a run moving between backends.