werf is not just alive. It is running a tight release train around Kubernetes delivery, with 18 release events in 30 days and 21 GitHub releases in 90 days. For a CI/CD tool that sits between Git, image builds, Helm, and Kubernetes deploys, that pace matters.
The official site positions werf as a consistent delivery tool for Kubernetes, with Git as the source of truth, plus build, test, artifact distribution, and deploy in one workflow. The GitHub repository says the same thing in shorter form: efficient and consistent software delivery to Kubernetes.
The recent release pattern is the signal. The payload shows channel updates across alpha, beta, early access, and stable. GitHub release pages back that up, with v2.69.0 labeled alpha and beta, v2.68.2 labeled early access and stable, and v2.68.1 as a regular release.
That is not random activity. It looks like a staged promotion model, where fixes and features move through channels instead of landing as one big undifferentiated release.
v2.69.0 adds host cleanup support for absolute storage units and fixes build, import, Buildah, ci-env, and host cleanup issues. v2.68.2 is narrower, a deploy fix that retries on webhook unavailable errors. v2.68.1 is broader, with fixes around build cache behavior, deploy retries, synchronization requirements, import checksums, and logging.
The bet is clear: werf wants to reduce the boring, expensive failures in Kubernetes delivery. Not the demo-path failures. The annoying production-path failures, registry coordination, build cache misses, webhook flakiness, image reference handling, and cleanup behavior.
It is OSI-approved open source under Apache-2.0, based on the ToolVitals openness payload and the repository license signal. ToolVitals tracks 4,686 GitHub stars, a 95 health score, a 92 shipping score, and a 94 ToolVitals score, with 94 data confidence.
What ToolVitals cannot infer
ToolVitals can see release events, stars, scoring signals, SSL and uptime style checks, and repository metadata. It cannot tell you whether werf fits your deployment model, whether the UX is pleasant, or whether the internal architecture is clean.
It also cannot prove user satisfaction, revenue, support quality, or production reliability. A retry fix for Kubernetes webhook errors is a good maintenance signal. It is not proof that every werf deployment is safe.
The release feed is busy, but some events are channel promotions for the same version. So the right reading is not “18 totally separate product launches.” The conservative reading is better: werf has active release management and frequent channel movement.
How it compares
Pulumi is the closest DevOps comparison in the related data. It has 25,222 stars, a 100 shipping score, and 20 release events in 30 days. werf is smaller at 4,686 stars, but its 18 release events in 30 days puts it near Pulumi on short-term shipping activity.
Jenkins is much larger in mindshare and has 25,277 stars in the payload, but ToolVitals shows only 8 release events in 30 days. That makes werf look more like a fast-moving specialized Kubernetes delivery tool than a slower, broad CI institution.
The comparison cuts both ways. Pulumi and Jenkins have larger star counts. werf has a narrower job and strong recent activity around that job.
Recommendation
If your team deploys to Kubernetes with Git, Helm, and container images already in the loop, evaluate werf because its current release activity is concentrated on the exact failure zones that make CI/CD painful: build determinism, deploy retries, image handling, cache behavior, and cleanup.
Do not adopt it because the score is high. Use the score as a filter, then test the workflow against your real pipelines. werf looks maintained and serious, but ToolVitals cannot replace a hands-on trial in your own cluster.