Anybuild documentation
Anybuild vs Railpack
Two automatic build systems with different outputs, execution models, and extension points.
Summary
Both tools detect application source and derive a build plan. Railpack is centered on generating and executing BuildKit plans for container images. Anybuild is centered on an editable Starlark project definition that can build locally or in Docker and run locally or as a Wasmer package.
Feature comparison
| Area | Anybuild | Railpack |
|---|---|---|
| Primary output | Local artifacts and Wasmer packages; Docker can isolate builds. | OCI images or exported filesystems produced through BuildKit. |
| Project configuration | Generated, editable Starlark plus typed provider config. | railpack.json patches over an automatically generated plan. |
| Execution | Local or Docker build backend; local or Wasmer runner. | BuildKit daemon/frontend and container runtime images. |
| Customization | Compose provider build structs, steps, commands, mounts, volumes, and services. | Patch steps, layers, caches, commands, and deploy inputs in JSON. |
| Documented integration surface | Synchronous Rust SDK plus a thin CLI. | CLI plus a BuildKit frontend for platform integration. |
| Integrated deployment | Wasmer publishing and deployment-config output. | Image production; a hosting platform performs deployment. |
Choose Anybuild when
- You need the same project plan to work on a host, in Docker, and with Wasmer.
- You want application-owned, programmable Starlark customization.
- You are embedding orchestration through a Rust API and structured events.
- You want an integrated path from detection to Wasmer publication.
Choose Railpack when
- Your required artifact is an OCI container image.
- Your platform already operates BuildKit and its cache/registry model.
- You prefer declarative JSON plan patches over a programmable project definition.
- You need Railpack's broader current language-provider catalog.