Kaniko Alternatives

Research Date: 2026-02-20
Topic: Container Image Building Tools to Replace Kaniko

Executive Summary

Google officially archived the Kaniko project in June 2025, ending active development and maintenance¹². This research evaluates the leading alternatives for unprivileged, Kubernetes-native container image building, analyzing their features, trade-offs, and suitability as Kaniko replacements.

Key Finding: BuildKit (rootless mode) offers the best drop-in replacement for most teams, while Buildah provides superior isolation for security-sensitive environments. Specialized tools like werf add value for teams needing advanced CI/CD integration.

Background: Why Kaniko Was Archived

Kaniko was developed by Google to enable container image building inside Kubernetes without requiring privileged access or Docker-in-Docker³. However, the project had been effectively unmaintained since mid-2024, and in June 2025 the repository was archived and made read-only¹².

GitLab has also announced complete migration away from Kaniko, citing security and maintenance concerns².

Risks of continuing with Kaniko:

• No security patches for future vulnerabilities
• No support for new Dockerfile features
• Limited multi-architecture support
• Approximately 40% slower than modern alternatives⁴

Alternatives Analysis

1. BuildKit (Docker/Moby) ⭐ RECOMMENDED

Status: Actively maintained by Docker/Moby organization

Pros:

• Performance: Up to 3x faster than Kaniko⁴
• Native multi-architecture support: Build multi-platform images simultaneously
• Modern Dockerfile features: Full support for BuildKit-specific syntax (secrets, cache mounts, etc.)
• Parallelization: DAG-based concurrent building
• Content-addressable caching: More efficient layer caching
• Rootless mode: True unprivileged execution available⁵
• Industry standard: Default builder for Docker; extensive ecosystem
• Windows containers: Full support for Windows builds⁴

Cons:

• Requires kernel namespace support (user namespaces) for true rootless mode
• More complex configuration for Kubernetes-native builds
• Some features require BuildKit daemon or daemonless wrapper

Best For: Teams already using Docker; need multi-arch support; prioritize build performance

CI/CD Example (GitLab CI):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

build-rootless:
  image:
    name: moby/buildkit:rootless
    entrypoint: [""]
  variables:
    BUILDKITD_FLAGS: --oci-worker-no-process-sandbox
  before_script:
    - mkdir -p ~/.docker
    - echo '{"auths":{"$CI_REGISTRY":{"username":"$CI_REGISTRY_USER","password":"$CI_REGISTRY_PASSWORD"}}}' > ~/.docker/config.json
  script:
    - |
      buildctl-daemonless.sh build \
        --frontend dockerfile.v0 \
        --local context=. \
        --local dockerfile=. \
        --output type=image,name=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA,push=true

2. Buildah (Red Hat/Containers) ⭐ SECURITY-FOCUSED

Status: CNCF Sandbox project (as of January 2025)⁶; actively maintained by Red Hat

Pros:

• True rootless: Builds containers as unprivileged user without any privileged escalation⁷
• No daemon required: Fork-exec model; builds as direct child process
• Fine-grained control: Step-by-step interactive building; scriptable⁸
• Multiple isolation levels: chroot, rootless, or privileged mode
• OCI-native: Native OCI image support; creates standards-compliant images
• Podman integration: Part of broader container ecosystem
• Better performance: Lower memory consumption and better disk utilization vs Kaniko⁷

Cons:

• Learning curve: More commands/flags than Docker-style interface
• Limited Dockerfile feature support compared to BuildKit
• Multi-architecture support requires additional tooling
• Slower than BuildKit for some scenarios

Best For: Security-sensitive environments; need fine-grained image control; already using Podman

CI/CD Example:

1
2
3
4
5
6
7

buildah-job:
  image: quay.io/buildah/stable
  script:
    - sed -i 's/^mount_program =/#/' /etc/containers/storage.conf
    - sed -i 's/^mountopt =/#/' /etc/containers/storage.conf
    - buildah build --isolation rootless -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - buildah push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

3. werf (CNCF Sandbox Project) - ADVANCED CI/CD

Status: CNCF Sandbox project; actively maintained by Flant

Pros:

• Uses Buildah/BuildKit as backend: Leverages proven builders while adding features
• Content-based tagging: Automatic intelligent tagging based on image content
• Advanced caching: Automatic layer caching with dependency awareness
• Git integration: Tight integration with git workflows
• Nelm deployment: Built-in Helm-based deployment engine
• CI/CD native: Purpose-built for GitLab CI, GitHub Actions, Argo CD⁹
• Incremental builds: Only rebuilds changed layers

Cons:

• Adds complexity; may be overkill for simple builds
• Smaller community than BuildKit/Buildah
• Requires learning werf-specific configuration

Best For: Complex CI/CD pipelines; need intelligent caching and deployment integration

4. img (Genuinetools) - NOT RECOMMENDED

Status: Effectively unmaintained (last significant activity ~2024)¹⁰

Pros:

• Standalone, daemon-less, unprivileged
• Compatible with Dockerfiles
• Simple CLI interface

Cons:

• Maintenance concerns: Project largely abandoned
• Outdated: Lags behind current standards
• Limited features: No multi-arch; limited caching

Verdict: Skip - use BuildKit or Buildah instead

5. Chainguard Kaniko Fork - TEMPORARY WORKAROUND

Status: Community maintenance by Chainguard¹¹

Pros:

• Drop-in replacement for existing Kaniko setups
• Security patches and maintenance
• Chainguard reputation for security-focused tooling

Cons:

• Not actively developing new features
• Limited scope: Maintenance only, not enhancement
• Dependency risk: Single vendor maintaining fork

Verdict: Short-term bridge only; plan migration to BuildKit or Buildah

Comparison Matrix

Recommendations

For Most Teams: BuildKit (Rootless Mode)

BuildKit offers the best balance of performance, features, and ecosystem support. It’s the default Docker builder and has the best multi-architecture support.

Migration path:

1. Replace Kaniko executor image with moby/buildkit:rootless
2. Use buildctl-daemonless.sh for daemonless builds
3. Add --oci-worker-no-process-sandbox flag for full unprivileged mode

For Security-Focused Environments: Buildah

When maximum isolation and true rootless operation is required, Buildah provides superior security guarantees with no privileged escalation needed.

When to choose:

• Shared CI environments with strict security requirements
• Need fine-grained control over build steps
• Already using Podman ecosystem

For Complex CI/CD Pipelines: werf

Teams with sophisticated deployment needs and heavy CI/CD investment should evaluate werf for its advanced caching, content-based tagging, and integrated deployment capabilities.

Migration Considerations

1. Test builds thoroughly: Each tool has subtle differences in how it interprets Dockerfiles
2. Cache strategy: Plan migration of build caches; formats are not compatible
3. Registry authentication: Each tool handles auth differently
4. Multi-arch strategy: If building multi-platform images, BuildKit is the clear choice
5. Security scanning: Re-scan base images after migration; layer structures differ

References

Conclusion

Primary Recommendation: Migrate to BuildKit (rootless mode) for the majority of use cases. It offers the best performance, most active development, and broadest ecosystem support while maintaining security through true rootless execution.

Secondary Option: Choose Buildah when you need maximum isolation or when working in environments where even minimal privilege escalation is unacceptable.

Avoid: img (unmaintained) and community Kaniko forks (maintenance-only, not forward-looking).

The migration from Kaniko should be treated as a priority given the security implications of using an unmaintained build tool.

Research completed: 2026-02-20
Repository: https://git.home.luguber.info/claw/research
Issue: https://git.home.luguber.info/claw/research/issues/24