Anybuild documentation
Anybuild vs Buildpacks
Compare Anybuild's project pipeline with the Cloud Native Buildpacks standard.
Summary
Cloud Native Buildpacks are a standardized way to transform application source into OCI images through buildpacks, builders, and lifecycle phases. Anybuild is a project orchestration SDK and CLI whose providers produce a Serve plan for multiple build and runtime environments.
Feature comparison
| Area | Anybuild | Cloud Native Buildpacks |
|---|---|---|
| Detection unit | A built-in scored provider selected once per project. | One or more buildpacks selected by lifecycle detection and order groups. |
| Orchestrator | Anybuild SDK operation and evaluated Serve plan. | CNB lifecycle phases inside a builder/platform. |
| Output | Backend artifacts and optional Wasmer package. | A runnable OCI application image. |
| Customization | Editable Starlark and provider composition. | Buildpack APIs, project descriptors, bindings, and builder configuration. |
| Runtime | Local process or Wasmer runner. | Container runtime using the builder's referenced run image. |
| Standard lifecycle features | No current rebase or SBOM contract in the public plan model. | Standard analyze, detect, restore, build, export, rebase, and SBOM mechanisms. |
Choose Anybuild when
- You need a non-container local path or a Wasmer-native package.
- You want one editable project definition instead of authoring a buildpack.
- You need a small synchronous Rust SDK embedded in another tool.
Choose Buildpacks when
- OCI images are the required portable artifact.
- You need ecosystem-standard builders, lifecycle APIs, rebasing, or SBOM metadata.
- Your organization centralizes build policy in shared buildpacks and builder images.