Installer werf avec Homebrew, Nix, zypper

Liens du projet

• Page d'accueil
• Dépôt
• Docs amont
• Page du gestionnaire de paquets

Commandes et alias

• werf

Historique du projet

The project began in January 2016 under the earlier `dapp` name, before Kubernetes deployment became central to its identity. The official tenth-anniversary history describes the starting point as an experiment in incremental Docker image building that later grew into an open source delivery ecosystem for Kubernetes applications.

In March 2017, dapp gained Kubernetes deployment via Helm charts, shifting the tool from image building toward end-to-end application delivery. The public GitHub repository dates to January 2016, and werf's own retrospective groups the pre-2019 period as the dapp and early werf era before the v1 line.

werf v1 covered the December 2018 through March 2020 transition, while the v1.1 and v1.2 eras added production-oriented behavior such as content-based tagging, distributed layer storage, bundles, and increasingly reproducible deployment artifacts. In May 2023, the project began moving away from its Helm fork toward Nelm, a Helm-compatible deployment engine developed as part of the broader werf ecosystem.

On December 13, 2022, CNCF accepted werf at Sandbox maturity. That gave the project formal cloud-native foundation status and framed it as a community project rather than only a vendor-maintained delivery tool.

Historique d'adoption

werf's README says it has been used in production since 2017 and that thousands of projects rely on it. The 2026 anniversary post gives a more concrete ecosystem snapshot: 4600+ GitHub stars, 1300+ releases, 18,000+ active projects using werf, 15,000+ commits, 60+ contributors, and 6000+ merged pull requests.

Its adoption pattern is strongest among teams that want CI/CD behavior in Git but do not want to replace their existing CI service. werf is designed to run inside GitLab CI, GitHub Actions, or other CI systems while owning the build, publish, deploy, tracking, and cleanup parts of a Kubernetes release.

Modes d'utilisation

A typical werf project keeps a `werf.yaml` file in the source tree and lets the CLI build container images, publish them to a registry, deploy Helm-compatible charts to Kubernetes, track rollout status, and clean old artifacts. This makes werf closer to an application delivery orchestrator than a single-purpose image builder.

In package terms, werf matters because it packages several common cloud-native primitives into one repeatable CLI workflow. That role also explains its related projects: Nelm for Helm-compatible deployment, trdl for update channels, kubedog for Kubernetes rollout tracking, and lockgate for synchronization.

Chronologie

• January 2016: project starts as dapp, focused on incremental Docker image building.
• March 2017: Kubernetes deployment via Helm becomes part of the tool.
• December 2018-March 2020: the v1 era establishes the werf identity.
• March-April 2020: content-based tagging and distributed layer storage improve image handling in concurrent CI environments.
• November 2020-April 2024: the v1.2 era adds bundle-oriented distribution and broader production delivery behavior.
• December 13, 2022: werf joins CNCF as a Sandbox project.
• May 2023: the deployment subsystem begins the move away from a Helm fork toward Nelm.
• April 2024 onward: werf v2 begins, with ongoing ecosystem work around Nelm and delivery tooling.

Sources

• https://api.github.com/repos/werf/werf
• https://blog.werf.io/werf-project-history-10-years-f092486e4224
• https://github.com/werf/werf
• https://werf.io/docs
• https://www.cncf.io/projects/werf/