Buildah is the OCI image builder from the containers project that also makes Podman. It builds from a Containerfile or from plain shell commands, without a daemon and, if you set it up, without root. It is under active development: the Buildah releases page marks v1.46.0 from October 21, 2026 as the latest, after v1.45.2 earlier that month.
People look elsewhere for practical reasons. Their CI already runs docker build and wants BuildKit features such as cache exports. They build Go or Java services and would rather skip the Containerfile entirely. Or they used Kaniko in Kubernetes and need to know what happened to it. The six picks below are grouped by those jobs, with the build engines first and the language-specific tools after.
Prices below are as of November 8, 2026. Our method is on How we review tools.
Quick comparison
| Tool | Best for | Price | Platforms |
|---|---|---|---|
| BuildKit with docker buildx | Dockerfile builds with cache export and multi-platform output | Free, Apache 2.0 | Daemon on Linux and Windows; client also on macOS |
| Podman (podman build) | One CLI to build, run and test images | Free, Apache 2.0 | Linux, macOS, Windows |
| Kaniko (Chainguard fork) | Existing Kaniko pipelines in Kubernetes CI | Source free; Chainguard images on request | Runs as a container on Linux |
| Cloud Native Buildpacks | Images from source code with no Dockerfile | Free, open source | pack CLI on Linux, macOS, Windows |
| ko | Go services without Docker | Free, open source | Anywhere Go builds |
| Jib | Java images from Maven or Gradle | Free, Apache 2.0 | Anywhere Maven or Gradle runs |
BuildKit with docker buildx
BuildKit is the build engine Docker switched to: since Docker Engine 23.0, docker build goes through Buildx and BuildKit by default. Used standalone, it is a buildkitd daemon plus the buildctl client, with either an OCI worker on runc or crun, or a containerd worker. Our containerd alternatives page explains that runtime layer.
Releases are frequent. v0.34.2 came out on November 3, 2026 with two security fixes, one for a daemon panic from resolver cache poisoning and one stopping clients from setting extended attributes outside the state directory, per the BuildKit releases page. The Dockerfile frontend reached 1.28.0 on October 7, 2026, which is where features like heredocs and cache mounts arrive first.
Best for: Teams whose pipelines already use docker build or buildx and want remote cache, bake files and multi-platform images.
Pricing:
- Free, Apache 2.0
- Docker Desktop, if you build through it on a laptop, follows Docker's own licence terms
Watch out for:
- buildkitd needs root by default. The rootless image works, but the daemonless example in the README runs it with seccomp and AppArmor set to unconfined.
- It is a long-running daemon, which is the very thing Buildah avoids; the daemon itself runs only on Linux and Windows.
Official site: BuildKit with docker buildx.
Podman (podman build)
Podman is not a different build engine. podman build calls Buildah's code, and the Podman v6.1.4 release from October 12, 2026 moved its bundled Buildah to 1.45.2. What Podman adds is everything after the build: run the image, open a shell in it, group containers into pods and generate systemd units with Quadlet.
That makes it the gentlest step for anyone who found Buildah's separate from, run and commit commands awkward and wants a Docker-style workflow without a daemon. Podman Desktop gives Mac and Windows users a GUI. Other engines that run the same images are on our Podman alternatives page.
Best for: Developers who want build, run and debug in one rootless CLI with Docker-like commands.
Pricing:
- Free, Apache 2.0
- Podman Desktop: free
Watch out for:
- It inherits Buildah's behaviour and bugs, and it trails Buildah releases: v6.1.4 ships 1.45.2 while Buildah itself is on 1.46.0.
- On macOS and Windows every build runs inside the podman machine Linux VM.
Official site: Podman (podman build).
Kaniko (Chainguard fork)
Kaniko builds a Dockerfile inside an ordinary container, with no daemon and no privileged pod, which made it the default in many GitLab and Kubernetes pipelines. Google archived the original repository on June 3, 2025 and its README now says the project is no longer developed or maintained. Two days later, Chainguard announced it had forked the code and would keep it open.
The fork at chainguard-dev/kaniko describes itself as the supported replacement and gets security patches and maintenance. Releases are tags only. The project publishes no container images, so you build the executor image yourself or buy Chainguard's kaniko images.
Best for: Teams with working Kaniko pipelines who want patches without rewriting CI.
Pricing:
- Fork source code: free, open source
- Chainguard kaniko, kaniko-warmer and FIPS images: price on request
Watch out for:
- The README says no major feature work is planned, so treat it as a maintained legacy tool rather than a long-term platform.
- The old gcr.io/kaniko-project images are unmaintained. Pipelines still pulling them get no fixes.
Official site: Kaniko (Chainguard fork).
Cloud Native Buildpacks
Buildpacks start from the source code instead of a Containerfile. Run pack build in a Node, Java, Python or Go project and a builder from Paketo, Heroku or Google detects the language, installs the runtime and produces an image. The Buildpacks site calls it a CNCF graduated project.
The pack CLI is current, with v0.40.10 released on October 21, 2026. Because the builder owns the base layers, many apps can get OS patches by rebasing onto a new run image rather than rebuilding every layer.
Best for: Platform teams that want every service built the same way without each repo maintaining a Containerfile.
Pricing:
- Free and open source
- Builders from Paketo, Heroku and Google are free to use
Watch out for:
- pack build still needs a container runtime. The pack release notes say Docker or Podman must be available.
- You give up line-by-line control. Unusual system packages or build steps mean writing your own buildpack or going back to a Containerfile.
Official site: Cloud Native Buildpacks.
ko
For Go services, ko removes the image build step as a separate thing. It runs go build on your machine, layers the binary onto a small base image and pushes the result, with SBOMs generated by default and multi-platform images from one command. No Docker install is needed, per the ko site, and it is a CNCF Sandbox project.
The current release is v0.19.1 from June 29, 2026. It also resolves image references in Kubernetes YAML, so ko apply builds and deploys in one go.
Best for: Go teams shipping small static binaries to Kubernetes.
Pricing:
- Free and open source
Watch out for:
- Go only, and best for a single binary with few OS dependencies. The site says it suits images with no cgo and no OS packages.
Official site: ko.
Jib
Jib does for Java what ko does for Go. You add the Maven or Gradle plugin, and it builds an optimised image without a Docker daemon or a Dockerfile, splitting dependencies, resources and classes into separate layers so small code changes push small layers. The Jib repository is Apache 2.0 with about 14.5k stars.
The latest plugin versions are jib-maven-plugin 3.5.2 and jib-gradle-plugin 3.5.4, with jib-core 0.28.2 for building images from Java code directly.
Best for: Spring Boot and other JVM services built with Maven or Gradle.
Pricing:
- Free, Apache 2.0
Watch out for:
- The README carries the line "This is not an officially supported Google product", and the repository has around 185 open issues.
- JVM only. Anything that needs extra OS packages in the image means a custom base image.
Official site: Jib.
How to choose
| If you need | Pick |
|---|---|
| Keep Dockerfiles but get remote cache and multi-platform builds | BuildKit with docker buildx |
| Build and run images from one daemonless CLI | Podman (podman build) |
| Unprivileged Dockerfile builds in an existing Kaniko pipeline | Kaniko (Chainguard fork) |
| One standard build for many languages, no Containerfile | Cloud Native Buildpacks |
| Go binaries straight to a registry | ko |
| Java images from the Maven or Gradle build | Jib |
When to stay with Buildah
Stay with Buildah if you build on Linux, want no daemon and need to script builds step by step, or if you run RHEL or Fedora where it is packaged and supported. It is also the safest replacement for Kaniko in GitLab or Tekton jobs, since rootless Buildah builds a Containerfile without a privileged pod and its project is shipping releases monthly. The Buildah releases show 1.43, 1.44 and 1.45 all getting patches in 2026.
Frequently asked questions
Is Kaniko deprecated?
Google's original Kaniko repository was archived on June 3, 2025 and is read-only. Chainguard maintains a fork with security patches but no planned feature work, and it does not publish free images. For new pipelines, rootless Buildah or BuildKit is the longer-term choice.
What is the difference between Buildah and Podman?
Buildah only builds images, and it lets you script each step with commands like buildah from, run and commit. Podman builds with Buildah's code but also runs, inspects and manages containers and pods. Pick Podman for a Docker-style workflow and Buildah for lean CI build steps.
Can BuildKit run without Docker?
Yes. BuildKit ships as its own buildkitd daemon and buildctl client, and it can use a runc or containerd worker. It still runs as a daemon, and root is the default unless you use the rootless image.
Does Buildah work on macOS or Windows?
Not natively. Buildah needs a Linux kernel, so on a Mac or Windows PC you run it inside a Linux VM, usually the one podman machine creates. ko and Jib are the exceptions in this list that build on any OS where Go or a JVM runs.
