werf is a CNCF Sandbox command-line tool, written in Go and licensed under Apache-2.0, that implements full-cycle CI/CD to Kubernetes for teams that already build container images and deploy with Helm but want one tool to carry an application from build through deploy, release artifacts and container registry cleanup.

What it is

werf is a CLI tool that implements full-cycle CI/CD to Kubernetes. It integrates into an existing CI system rather than replacing it, and it deliberately builds on familiar, reliable technologies: Git, Dockerfile, Helm and Buildah. The project lives in the cloud-native ecosystem, is hosted by the CNCF as a Sandbox project, and is the reference implementation of the workflow its authors describe as gluing those common technologies together into one delivery pipeline.

The concrete problem it solves is the hand-assembled glue that otherwise sits between those tools: separate image builds, separate Helm invocations, ad-hoc release bookkeeping, and scripts written to stop a container registry filling up with stale tags. werf folds all of that into a single command surface. Build and publish container images, test, deploy to Kubernetes, distribute release artifacts and clean up the container registry are presented as one complete application lifecycle. It also adds capabilities that plain Dockerfile-plus-Helm setups lack, including automatic build caching, content-based tagging, enhanced resource tracking and extra Helm capabilities.

Key capabilities

• Complete application lifecycle management in one CLI: build and publish container images, test, deploy to Kubernetes, distribute release artifacts, and clean up the container registry.
• Image builds from ordinary Dockerfiles, with Buildah listed among the project's topics as the build technology.
• Deployment configuration through Helm charts, extended with additional capabilities over upstream Helm.
• Automatic build caching and content-based tagging, so image identity follows image content.
• Enhanced resource tracking during deployment and release.
• A container registry cleanup approach that the README presents as unique to the project.
• Giterminism: Git-driven, deterministic configuration, named directly in the project's topic list alongside gitops, ci-cd and continuous-delivery.

Who uses it and how

• Production teams: werf has been used in production since 2017 and the README states that thousands of projects rely on it to build and deploy various applications.
• CI-driven shops: werf is designed to slot into a CI system of choice, so the pipeline stays in the team's existing CI rather than moving to a vendor.
• Framework teams: official guides provide ready-to-use examples for Node.js (JavaScript), Spring Boot (Java), Django (Python), Rails (Ruby) and Laravel (PHP).
• Individual developers and platform teams alike: the Getting Started guide covers setup and use both locally and inside a CI system.
• Supported user base: help runs through GitHub Discussions, GitHub issues, Stack Overflow under the werf tag, the #werf channel in the CNCF Slack workspace, and the Telegram chats werf_io and werf_ru.

Getting started

Installation and first use are handled by the Getting Started guide at https://werf.io/getting_started/, which sets up and exercises werf both locally and in a CI system. The README does not name a package manager, Docker image or compose file, so the guide at werf.io is the documented entry point, with reference material under https://werf.io/docs/ in multiple languages.

How it compares

Within this registry werf is unusual in that it does not compete with the tools it uses: Buildah performs the image builds, Helm renders and applies the Kubernetes manifests, and Git supplies the source of truth, so werf sits above them as the orchestrating layer. It is therefore closest to a pipeline tool than to a build tool or a package manager, and the README names no paid product that it is positioned to replace.

When to use it — and when not to

A self-hoster must already operate a Kubernetes cluster, a container registry and a CI system, because werf is a CLI that integrates into those rather than supplying them, and the README describes no hosted option. Teams without Kubernetes, or teams that do not want to keep Helm charts and Dockerfiles as the configuration format, should look elsewhere. The honest limitations are the project's Sandbox maturity stage and a README that stays high-level: installation, operational prerequisites and resource requirements are deferred to the external documentation, with 30 open issues and 4,721 stars at the time of writing.