werf as a Kaniko alternative for image building in Kubernetes for your CI

Evgeniy Frolov — Tue, 24 Jun 2025 09:02:54 +0000

What is Kaniko and why was it needed?

Kaniko is a tool for building OCI-compliant container images inside a container, developed by Google. Its main selling point is that you don't need root privileges or a Docker daemon to run it. It has gained widespread adoption as a solution for building images in Kubernetes, particularly on platforms such as GitHub Actions and GitLab CI.

Kaniko's benefits:

Security: No root privileges required (rootless).
Simplicity: Easy to run as a Job or container in Kubernetes.
Compatibility: Supports regular Dockerfiles.

Kaniko is no longer supported — what's next?

In June 2025, the public Kaniko repository was archived and became read-only, which effectively means its active support and development have ended.

While some forks have already emerged (most notably, the one by Chainguard), they are primarily focused on maintenance (bug fixes and security) rather than active development. That is why many users are on the hunt for a new tool (or will be in the foreseeable future) to replace Kaniko.

Here are the most popular Kaniko alternatives:

BuildKit by Docker/Moby (especially when used with docker buildx).
Buildah by Red Hat (part of the Podman ecosystem). By the way, it just became a CNCF Sandbox project in January 2025.

Why you should try werf and how to get started

werf is an Open Source, production-ready, higher-level tool designed not only for building but also for delivering container images to Kubernetes, with an emphasis on reproducibility, efficient caching, and CI/CD integration. It works with any CI system you prefer and is a CNCF Sandbox project.

Here's what werf brings to the table:

A Kubernetes-native architecture;
Support for rootless Buildah or BuildKit as the build backends;
Transparent handling of cache and artifacts;
Seamless integration with other software delivery tools for Kubernetes, including GitLab, GitHub Actions, and Argo CD.

Being a higher-level, opinionated solution, werf goes far beyond a simple building block like Kaniko and helps you tackle the following CI/CD challenges:

Secure and efficient image building;
Automatic caching and tagging;
Reliable deployment of Helm charts and release management in Kubernetes;
Distribution of release artifacts;
Smart container registry cleanup;
Quick integration with GitHub and GitLab.

So, how do you integrate werf into a CI/CD system? Typically, the integration process only requires adding the werf converge command to your pipeline. It will build the image, push it to the registry, and deploy it to the Kubernetes cluster.

werf usage examples

To give you a more practical idea of how werf integrates with existing CI systems, here are two configurations. The following .github/workflows/converge.yml file lets you easily integrate werf into GitHub Actions:

name: prod
on:
  push:
    branches:
      - main

jobs:
  prod:
    name: prod
    runs-on: arc-runner-set
    container:
      image: registry.werf.io/werf/werf:2-stable-ubuntu
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - run: |
          . "$(werf ci-env github --as-file)"
          werf converge
        env:
          WERF_ENV: prod
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          WERF_KUBECONFIG_BASE64: ${{ secrets.KUBECONFIG_BASE64 }}

And here is how you can integrate werf into your GitLab CI/CD pipeline:

stages:
  - prod

default:
  image:
    name: "registry.werf.io/werf/werf:2-stable-ubuntu"
    pull_policy: always
  before_script:
    - source "$(werf ci-env gitlab --as-file)"
  tags: ["<GitLab Runner tag>"]

prod:
  stage: prod
  script:
    - werf converge
  environment:
    name: prod
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "schedule"
      when: manual

For more detailed instructions on using werf to deploy your applications to Kubernetes using a preferred CI/CD system, refer to the project's official Getting Started guide.

The documentation covers numerous use cases, offers interactive scenarios, and provides ready-to-use CI configurations. It is a good fit for beginners as well as experienced DevOps engineers.

Conclusion