Celebrating 9 years of facilitating best practices for software delivery in Kubernetes by revisiting the project’s achievements in 2024.

Imagine Han Solo driving the Millennium Falcon without his loyal co-pilot Chewbacca. No matter how he’s skilled, flying alone in space would be a perilous mission. This is exactly what Werf represents! It’s the Chewbacca of your Kubernetes deployments, always there to back you up.

In werf 2.0 and Nelm, we took it a step further and replaced 3-Way Merge with Server-Side Apply (SSA), a more modern and robust mechanism for updating Kubernetes resources. It solves all 3-Way Merge issues and ensures that resources in the cluster are updated correctly during deployments.

Nelm, a part of the Werf project, is emerging as a promising alternative to Helm. It is a fully backwards compatible reimplementation of Helm, with improvements aimed at making it more robust and feature-rich.

In the recent werf v2.0 release, the CI/CD solution has unveiled a new deployment engine called Nelm. It has replaced Helm while retaining backward compatibility and introducing new prominent features. You can try them in werf right now with other tools to come around the corner. Let’s explore the history of the project and examine the path it’s traveled to this transformation.

For four years, we have been developing and improving werf 1.2. Now, we are proud to unveil werf 2.0 stable! It accumulates all changes delivered to werf throughout the last 300+ releases and comes with Nelm — our new deployment engine, replacing Helm. Nelm is backward compatible with Helm, so there’s no need to make any special changes to the charts — you can use them just like before.

Werf is a Continuous Integration/Continuous Deployment (CI/CD) tool that simplifies the process of building, testing, releasing, and deploying applications to Kubernetes. It’s an Open Source project under the Cloud Native Computing Foundation (CNCF), designated as a sandbox project as of December 13, 2022​.

Werf was designed to address the complexities and inconsistencies encountered in CI/CD processes, especially when deploying applications to Kubernetes. It originated in a professional services company that provided DevOps as a Service, Flant. The motivation behind its creation was to standardize and automate the implementation of CI/CD pipelines across various projects​.

In this tutorial, you will get to know GitOps and the GitOps agent werf.

After finishing this tutorial, you will know about the core ideas of GitOps. You will know how to setup an end-to-end GitOps workflow using werf and will be able to deploy applications to different environments (development, production) with a simple commit.

Welcome to this blog post, where we explore the fascinating world of Werf a remarkable CI/CD tool that is transforming the way we approach software development and deployment.

As a standout member of the CNCF (Cloud Native Computing Foundation) project family, Werf brings a fresh perspective and cutting-edge capabilities to the ever-evolving field of DevOps.

In this presentation, we will explore werf, an Open Source CLI tool that recently became a CNCF project, designed to implement consistent and efficient software delivery to Kubernetes with your CI/CD system of choice.

This article takes a look at a new experimental operation mode that connects the werf Open Source utility with Argo CD. It combines the features and user-friendliness of both tools into a unified CI/CD process. Note that these werf features are still being refined. That said, you can take the opportunity to check them out and see if they are right for you.

Canary releases are quite a popular and well-covered phenomenon (see, for example, links to other articles on our blog below). But I would still like to briefly overview what they are used for.

Canary deployment is a good way to test new features on a subset of users. A specific subset of users is selected based on a particular attribute. At the same time, testing activities cannot affect the user experience on the main application version. The load between the two app versions should be allocated in a predictable fashion.

werf strives to make software delivery in Kubernetes consistent and efficient. Here's the story behind this project and a quick look at what it offers today.

werf is officially a Sandbox project in the CNCF (Cloud Native Computing Foundation) now. Here is a brief intro to the project, this change, and our nearest plans.

Custom readiness probes in initContainers with Helm vs. resource weights in werf.

Use this interactive lab launched directly in your web browser to learn how you can easily deploy applications to Kubernetes with werf.

werf is an Open Source tool for building applications and deploying them to Kubernetes. This article discusses the new experimental werf operating mode that does not require a Docker server to be run. You will learn how to ensure this mode works properly on your machine, build an image, and use the Kubernetes executor to automate builds in GitLab CI/CD.

This article looks at building a Docker image of a minimalistic application and deploying it to a Kubernetes cluster using the Open Source tool called werf.

This article discusses preparing and deploying a Kubernetes-based infrastructure for local development using a basic application as an example. Local development means you can change your app’s source code and instantly see how it works in K8s running on your computer.

werf is a CLI Open Source tool for building applications and deploying them to Kubernetes clusters. Version 1.2 features many new changes and improvements. We have been thoroughly testing and refining them as part of the Early-Access version over the last eleven months (since January 2021). Finally, we are pleased to announce that it has been promoted to Stable!

This article discusses the so-called review environments running in Kubernetes clusters. Why are these environments necessary and what are typical use cases for them? How to make a review environment pipeline in GitLab CI/CD? What potential problems can arise, and how to avoid them?

This article is the next installment in the “werf vs. …” series. In the previous article, we discussed the ways that werf differs from Helm. This article compares werf with an even more basic tool: Docker.

This article attempts to provide a detailed answer to a question we stumble upon every now and then: What is the difference between werf and Helm? At first glance, both of these tools seem to be designed with the same purpose: automating application deployment in Kubernetes. However, the reality is a little more complicated than that.

The werf tool is designed to easily integrate with any CI/CD system. The general approach to this process is provided in the epilogue, while the main part of this article discusses the practical example of organizing a CI process in Jenkins and Bitbucket.

After reading this article, you will learn how to:

• create a Jenkins Shared Library to store all CI scripts in one place and edit them via a single commit;
• integrate Jenkins with Bitbucket to trigger CI processes by committing to specific branches or by creating a tag.

GitOps is a modern way to make better IaC for delivering apps in Kubernetes. It is all about giterminism, idempotence, automation, observability… and many other exciting features! However, are you sure all this happens in the real world using existing approach and tools? Here’s our comprehensive analysis of GitOps and its features, comparison with CIOps as well as insights on how this all should be done to actually get what each DevOps engineer dreams of.

werf is a CLI tool that glues well-established software (Git, Docker, Kubernetes, Helm, a variety of container registries & CI systems) to facilitate applications’ delivery. In this webinar, developers, release engineers & SREs will learn how they can benefit from werf in their infrastructure, release management & CI/CD pipelines. Using Git as a single source of truth, we will build images of a simple Node.js application, push them into registry, deploy to Kubernetes and integrate with GitLab CI. You will also see how actual Kubernetes deployments are kept always in sync with your defined state via GitOps push-based approach.

While implementing CI/CD processes for a variety of developer teams, we've realised that container registries (Docker Registry, GitLab container registry, etc.) usually don't provide flexible & powerful policies to clean up the images that are not in use. As modern cloud-native applications development requires to deliver a huge amount of builds (images) to Kubernetes, you might end up with either an overfilled registry or lacking an important image in your infrastructure (or registry) when it's needed. Here are our thoughts on this issue and how we have resolved it away from the registries themselves, in our Open Source tool (werf).

This is the third post of a GitOps tools article collection. In this post, the author gets to know continuous integration and continuous deployment tool for Kubernetes — werf.

werf is our Open Source tool to build your applications and deploy them to Kubernetes — continuously & consistently. Today we are excited to announce that werf has learned to operate in a distributed mode!

Container registries tend to support the Docker Registry HTTP API, allowing their users to rely on the same tools to operate them. However, some implementations have their peculiarities and limitations. Thus, you have to take into account their specifics when using them as part of your CI/CD toolchain. That is exactly what happened when we decided to improve the way our werf GitOps utility manages the lifecycle of images.

werf is our Open Source GitOps tool to build your applications and deploy them to Kubernetes. The v1.1 release introduced a new feature in the image builder: the content-based tagging. Until now, the typical tagging strategy in werf involved tagging Docker images by a Git tag, Git branch, or Git commit. However, all these strategies have drawbacks that are fully resolved by implementing the new tagging strategy. In this article, we discuss its advantages.

werf is our Open Source GitOps tool to build your applications and deploy them to Kubernetes. As promised, the release of werf 1.0 marked the beginning of the era of new features and revising established approaches. Now, we are excited to announce the latest version (v1.1) of our tool which is a massive step in the development of its builder and laying the groundwork for the future.

You may already know our GitOps tool called werf — we have discussed it in several of our articles. Today, we would like to share our experience in building & deploying the site with our tool’s documentation, werf.io. Despite it is a regular static site, the building process is noteworthy as we use a dynamic number of artifacts.

We are often confronted with the challenge of adapting applications for running them in Kubernetes. When dealing with this challenge, we usually encounter many repetitive problems. In this article, we’ll focus on some of specific CI/CD processes.

In this article, timed to coincide with the werf release, we will provide a detailed description of what this version can and cannot do, as well as discuss our plans for future versions. However, let’s start with what the term “GitOps” means and what role werf has in the process of continuous integration and continuous delivery (CI/CD).

Let’s start with a theory. What are three-way-merge patches? How they’ve been invented, and why they are so essential for CI/CD processes with a Kubernetes-based infrastructure? And later, we will discuss the 3-way-merge process in werf, what modes are used by default, and how can you manage all this stuff.

Are you struggling with implementing CI/CD for many microservices in a efficient and elegant way? Here’s our current approach in solving this task using GitLab CI (thanks to its include keyword in .gitlab-ci.yml) and werf.

Let’s imagine that your application is written in some scripting language — e.g. Ruby — and you want to rewrite it in Golang. You may ask a reasonable question: what is the point in rewriting a program that is up and running?..

This article should be useful if you create & apply Helm charts for Kubernetes using the existing solutions drawn from the chart repositories.

Better late than never. The story of how we almost made a major mistake by not implementing support for building images using regular Dockerfiles.

We are excited to announce werf — Open Source, Go-native and simply powerful DevOps tool bringing the CI/CD implementation based on Kubernetes to the next level.