> ## Documentation Index
> Fetch the complete documentation index at: https://buildcharts.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Comparisons

> How BuildCharts compares to related build and CI/CD approaches.

BuildCharts overlaps with several familiar CI and build patterns, but its model aligns more closely with Helm-style charts: versioned build logic is distributed through OCI registries, while Docker Buildx provides the execution layer, caching, and local parity with CI.

## What BuildCharts optimizes for

BuildCharts is not a hosted CI platform. It is a build plan generator:

* You define intent in `build.yml`
* BuildCharts resolves OCI-hosted chart templates
* It generates `.buildcharts/docker-bake.hcl`
* Docker Buildx Bake executes the plan locally or in CI

That makes BuildCharts strongest when you want:

* Local and CI parity with the same Docker execution layer
* Centrally versioned build logic across many repositories
* OCI-based distribution and digest pinning

## Scope

It does not replace your CI/CD platform.

BuildCharts also does not:

* Manage deployments or runtime configuration
* Host secrets or artifacts for you
* Package or publish charts/templates for you
* Provide a built-in signing or trust system for charts

## Comparison with common alternatives

| Tool                                           | Strength                                                   | Tradeoff vs BuildCharts                                                                |
| ---------------------------------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| [Dagger](https://github.com/dagger/dagger)     | Programmable container-native pipelines with SDK workflows | Introduces its own execution/programming model instead of `build.yml` + generated Bake |
| [Earthly](https://github.com/earthly/earthly)  | BuildKit-based automation with local/CI parity             | Uses Earthfile DSL and different authoring model                                       |
| [Tekton](https://github.com/tektoncd/pipeline) | Kubernetes-native pipelines at platform scale              | Requires Kubernetes control plane and is less local-first                              |
| [Buildkite](https://github.com/buildkite)      | Mature hosted orchestration and job controls               | Higher platform coupling than local-first generated Bake plans                         |
| [Bazel](https://github.com/bazelbuild/bazel)   | Strong hermetic builds and caching for large mono-repos    | Steeper adoption and different build graph model                                       |
| [Nix](https://github.com/NixOS/nix)            | Reproducible environments and package builds               | Different ecosystem and workflow than Docker Buildx-centric pipelines                  |

## When it fits

BuildCharts tends to fit well when you:

* Already use Docker and BuildKit for builds
* Want to centralize build logic across many repositories
* Want the same build plan to run locally and in CI
* Benefit from parallel builds and BuildKit caching

## When it doesn't

BuildCharts tends to be a poor fit when you:

* Cannot run Docker daemons or BuildKit in your environment
* Have highly bespoke build steps that do not map well to Docker-based stages
* Have very constrained runners where Bake parallelism and caching add more overhead than benefit

## Related systems and inspirations

These are useful references, but they solve different layers than BuildCharts:

* [dotnet/arcade](https://github.com/dotnet/arcade)
* [facebook/buck](https://github.com/facebook/buck)
* [twitter/pants](https://github.com/twitter/pants)
* [netflix/nebula](https://github.com/nebula-plugins)

## Docker and BuildKit references

BuildCharts relies on Docker Buildx/BuildKit behavior. These references are useful when evaluating tradeoffs:

* [Build cache backends](https://docs.docker.com/build/cache/backends/registry/)
* [Build contexts](https://docs.docker.com/build/concepts/context/#git-repositories)
* [Dockerfile `ONBUILD`](https://docs.docker.com/reference/dockerfile/#onbuild)
* [docker/metadata-action](https://github.com/docker/metadata-action?tab=readme-ov-file)

## Practical takeaway

BuildCharts is a good fit if you want Docker-native, chart-driven build standardization without introducing a separate pipeline runtime. If you need deep hosted orchestration, non-Docker execution engines, or Kubernetes-native pipeline control planes, other alternatives may be a better choice.