Pipeline Architecture
How operation context, providers, Starlark, backends, and runners fit together.
Operation context
Every SDK call creates an operation-scoped context containing the effective environment, process-I/O policy, event reporter, and detected secret values. Backends and runners use this context instead of reading or mutating process-global state.
Providers
Provider modules detect source layouts and load typed configuration. The registry currently contains Laravel, Hugo, MkDocs, Python, WordPress, PHP, node-static, Node.js, Jekyll, Go, and staticfile providers.
Starlark evaluation
The evaluator loads bundled or project-local .bzl modules, exposes build builtins, and converts the final serve call into Rust plan types. Backend and runner path layouts are supplied during evaluation, so the same definition resolves correct artifact paths for each environment.
Backends and runners
| Layer | Implementations | Responsibility |
|---|---|---|
| Build backend | Local, Docker | Execute steps and export artifacts. |
| Runner | Local, Wasmer | Prepare packages, map commands, run, and deploy. |
State layout
The workspace's .anybuild directory separates local, Docker, Wasmer, volume, and subdirectory state. Mounts have backend-specific build paths and runner-specific serve paths; Wasmer maps the app to /app and named mounts to /opt.