< woml />
View on GitHub

Remote Execution Targets

A remote target places one executable step attempt on an authenticated worker near a private service or host. The coordinator still owns admission, scheduling, retries, waits, locks, and run settlement. A target is a logical name, not a hostname or credential embedded in the workflow.

Place a step

Add a literal target to the step that needs remote execution:

WOML
<step id="migrateDatabase" target="production-private" timeout="20m">
  <script>
    const result = await services.process.run({
      executable: "bun",
      args: ["run", "database:migrate"]
    }, { name: "database-migration" });
    return { exitCode: result.exitCode };
  </script>
</step>

The complete script attempt runs on the target. Omitting target keeps local execution. Remote placement never silently falls back to local execution if a worker is unavailable.

Configure and inspect a target

Operators bind target names to allowed workers, trust material, capacities, and policies outside WOML source. Check the registry and trust before activation:

Terminal
woml target check production-private --registry .woml/targets.json --trust .woml/target-trust.json
woml target inspect production-private --registry .woml/targets.json --trust .woml/target-trust.json --json
woml dispatch inspect dispatch_<sha256> --state .woml/state.sqlite --json

Workers execute only an authenticated, integrity-bound attempt. They resolve permitted secrets locally and report facts to the coordinator; they cannot schedule downstream work or enlarge policy.

Handle lost workers safely

If a worker disappears after an effect may have started, the outcome is ambiguous. WOML does not automatically retry a possibly completed operation. Restore the worker or inspect its journal and the external system, then reconcile the dispatch explicitly with a reviewed reason. Drain a target before maintenance so it stops accepting new attempts without abandoning accepted ones.