Kaniko Is Dead: Google Quietly Archived It in June 2025 — What Rootless BuildKit Means for a Git-Push PaaS's Image-Build Path

On June 3, 2025, Google archived the Kaniko repository. No blog post, no migration guide, no successor project named — just a GitHub issue titled "State of Kaniko: Unmaintained?" that quietly confirmed what the commit graph had been suggesting for a year, followed by the repo flipping to read-only. If your build pipeline runs a tenant's Dockerfile inside a Kubernetes pod without a privileged Docker socket, there is a good chance Kaniko is the tool doing that job right now, and it is no longer going to get a fix for the next container-escape CVE.

Why this matters more than a typical dead-tool story​

Most tool-abandonment posts are irrelevant to anyone who isn't already using the tool. This one isn't, because Kaniko didn't just do image builds — it solved a specific, narrow problem that every self-hosted, multi-tenant, git-push PaaS runs into the moment it lets untrusted users supply a Dockerfile: how do you build an OCI image inside a Kubernetes pod without giving that pod root, a privileged security context, or a mounted /var/run/docker.sock?

The naive answer — mount the host's Docker socket into the build container — hands whoever controls that pod full control of the node's container runtime, and by extension every other tenant's workload running on it. That's not a hypothetical; it's the default "just get builds working" shortcut a lot of internal CI setups still take, and it's exactly the failure mode a multi-tenant build service can't afford.

Kaniko's answer was to skip the daemon entirely: it parsed a Dockerfile itself, executed each instruction inside its own build container, and assembled the resulting filesystem layers directly, all without ever calling out to dockerd or requiring CAP_SYS_ADMIN. That made it, for most of the last eight years, the default answer to "how do I build container images on Kubernetes without a privileged sidecar" — the exact requirement a git-push PaaS's build pipeline has for every tenant push.

Kaniko being unmaintained doesn't mean it stops working tomorrow. It means the thing every platform team should actually worry about — someone finding a container-escape bug in an unmaintained build tool that routinely ingests untrusted Dockerfiles from strangers — now has no one on the other end to fix it.

What "archived" concretely changes — and what it doesn't​

It's worth being precise about what Google actually did, because "archived" gets thrown around loosely:

• The repository is read-only. No new commits, no accepted pull requests, no issue triage from Google. thehapyone's writeup and the archived-repo banner itself confirm this is a hard stop, not a slowdown.
• Existing images keep working. gcr.io/kaniko-project/executor doesn't disappear from your registry or stop running. Nothing breaks on July 12, 2026, or any specific date after the archival.
• No CVE patches, ever, from the original maintainers. This is the part that actually matters on a timeline. Kaniko parses and executes arbitrary, tenant-supplied Dockerfiles — precisely the kind of attack surface where an unpatched vulnerability isn't theoretical risk, it's a queue of unknown bugs with no one fixing them.
• A community fork exists, but it's not the same guarantee. Chainguard forked the project to keep a maintained lineage alive for teams that can't migrate immediately. That's a legitimate stopgap — but it's a vendor-adjacent fork stepping in where Google stepped out, not Google's own continued investment, and it doesn't come with an upstream roadmap commitment.

So the honest framing isn't "Kaniko will break your builds this quarter." It's "the clock is running on an unpatched, internet-facing, untrusted-input parser sitting in your build path, and there's no PR queue fixing it anymore." That's a migration to plan, not a fire to put out today — which is exactly why it's easy to defer indefinitely unless something forces the question.

Rootless BuildKit is the closest real successor — here's the actual migration​

The tool that already does what Kaniko did, on an actively maintained upstream, is BuildKit running in rootless mode. Same core property Kaniko offered — no privileged Docker socket, no Docker-in-Docker sidecar — but as a daemon (buildkitd) running as an unprivileged user via rootlesskit, rather than Kaniko's daemonless single-shot executor. The two aren't identical architectures, but they solve the same problem for the same reason, and BuildKit is the tool Docker itself has invested in for years, not a side project someone stopped funding.

The concrete migration path:

# 1. Run BuildKit rootless in the build pod (moby/buildkit:rootless image)
#    BUILDKITD_FLAGS is required for rootless-in-Kubernetes — see the
#    security caveat below before you set this in production.
export BUILDKITD_FLAGS="--oci-worker-no-process-sandbox"
 
# 2. buildctl-daemonless.sh starts buildkitd, runs the build, and tears
#    the daemon down again — closest thing to Kaniko's "just run it" model
buildctl-daemonless.sh build \
  --frontend dockerfile.v0 \
  --local context=. \
  --local dockerfile=. \
  --opt filename=Dockerfile \
  --output type=image,name=registry.example.com/tenant/app:latest,push=true

That table is the shape of the decision, but two of those rows — cache and kernel requirements — are exactly the things that look like a drop-in swap on paper and then quietly break a build pipeline in production. They're the re-verification list, not a footnote.

What a git-push PaaS has to re-verify before flipping the switch​

This is the part the "just switch to BuildKit" advice usually skips, and it's the actual engineering work behind the headline.

1. Registry layer caching isn't a 1:1 flag swap. Kaniko cached layers with a single --cache flag pointed at a registry. BuildKit splits this into --cache-to and --cache-from, each with a type=registry backend and a choice between min mode (only layers that land in the final image get cached — smaller, faster to push/pull) and max mode (every intermediate layer gets cached — bigger, but far more likely to hit on a partial rebuild). For a multi-tenant build service where most rebuilds are "one dependency changed, rest of the layers are identical," picking the wrong mode is the difference between a 90-second incremental build and rebuilding from scratch every time. This needs its own load test against real tenant Dockerfiles before it ships, not an assumption that the equivalent flag exists and behaves the same.

2. --oci-worker-no-process-sandbox is a real security trade-off, not a compatibility checkbox. That flag disables BuildKit's internal process-isolation sandbox — without it, rootless BuildKit frequently can't run at all inside a standard Kubernetes pod. With it, a malicious RUN step in a tenant's Dockerfile can see and potentially signal other processes inside the same build container (not the host — the isolation boundary that matters here is still the pod), a materially different risk profile than Kaniko's daemonless model ever had. This is a decision to make deliberately per your isolation architecture (e.g., what runs alongside the build process in that pod), not a flag to copy from a blog post's example and forget about.

3. The pod spec needs real changes, not just a new image. Rootless BuildKit inside Kubernetes needs seccompProfile and appArmorProfile set to Unconfined on the build pod, a kernel ≥ 5.11 on every node that runs builds (or a fuse-overlayfs fallback path verified working — it's slower and has its own edge cases), and user.max_user_namespaces raised on the host via sysctl. None of that is a Kaniko concern today, and all of it is a fleet-wide node-image and pod-spec change that needs to land before the first tenant build runs on it — not discovered when the first build silently fails on a node that doesn't have the sysctl set.

None of these three are reasons to stay on Kaniko — an actively maintained upstream that fixes its own CVEs is worth all three of them. They're the difference between "swapped the build tool and it worked in staging" and "swapped the build tool and tenants started seeing builds fail on a subset of nodes three weeks later." Budget the re-verification, don't skip it.

The part tenants never see, which is exactly the point​

The build tool underneath a git push is infrastructure a tenant is never supposed to think about — they push code, they get a running service, and whether that image got assembled by Kaniko's executor or BuildKit's daemon is (correctly) invisible to them. That invisibility is the whole design goal of a git-push platform. But it means the platform operator carries 100% of the burden of noticing when a load-bearing piece of that invisible pipeline goes unmaintained, and migrating it before "it still works today" quietly becomes "it still works today, on a tool nobody's patching."

If you're evaluating or running a self-hosted git-push platform, "is the tool that turns a Dockerfile into a running container itself actively maintained" belongs on the same due-diligence list as the platform's own release cadence — it's exactly the kind of dependency that stays invisible until an unpatched CVE makes it everyone's problem at once. If you're running your own Kaniko-based build service and this is the first you're hearing that the clock started in June 2025, that's the sign it's time to schedule the migration rather than wait for the CVE that makes the decision for you.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources​

• State of Kaniko: Unmaintained? · Issue #3348 · GoogleContainerTools/kaniko
• 💔 The End of an Era: Kaniko Has Been Archived - thehapyone
• Fork Yeah: We're Bringing Kaniko Back - Chainguard
• GoogleContainerTools/kaniko on GitHub
• moby/buildkit — rootless mode docs
• Rootless mode - BuildKit (crazymax.dev)
• Rootless container builds on Kubernetes — Kubernetes @ CERN
• Cache storage backends - Docker Docs