● Beta — KubeEra is in active development. Profiles are live; AI-perception measurement is rolling out.
KubeEra
K

ko

SandboxApp Definition & Delivery
Open source · CNCF · CNCF Sandbox · Apache-2.0

ko is a build tool that turns Go source code into container images without a Dockerfile, a Docker daemon, or a separate build stage in CI.

updated 2026-07-01

What it is

ko is a build tool that turns Go source code into container images without a Dockerfile, a Docker daemon, or a separate build stage in CI. It resolves Go import paths, cross-compiles statically, and constructs an OCI image layer-by-layer directly, then pushes it to a registry. It also rewrites Kubernetes YAML on the fly — reference ko://github.com/you/app in a manifest and ko apply will build, push, and substitute the resolved image digest before applying. No layer caching hacks, no multi-stage Dockerfile maintenance for Go binaries.

It does one job: package Go binaries as minimal, reproducible container images. It does not build multi-language images, does not handle non-Go runtimes, and is not a general CI/CD tool.

Who builds it and why

ko started at Google, targeting the pain of building and deploying Go services to Kubernetes without dragging Docker into every developer's laptop and CI pipeline. It was donated to CNCF and now sits in Sandbox. Heavy usage and contribution has come from the Knative, Tekton, and broader Kubernetes tooling ecosystem — projects that ship a lot of small Go controllers and need fast, minimal, distroless-by-default images. 123 contributors on a single-purpose tool is a reasonable signal that it's load-bearing infrastructure for several other CNCF projects rather than a side project.

Production readiness signal

  • 8,461 GitHub stars, active commit history through mid-2026 — not abandoned.
  • 123 contributors — healthy bus factor for a narrow-scope tool.
  • Apache-2.0, standard permissive license, no legal friction.
  • Latest release v0.19.1 — past 1.0 in practice maturity (semver is conservative here; this is a stable, widely-depended-on tool despite sitting under v1).
  • Still CNCF Sandbox, not Incubating. Sandbox status reflects governance/process maturity requirements more than production risk — plenty of production Go shops (including inside Google and the Knative project itself) run on it daily.
  • No CVE-heavy history publicly notable; attack surface is small because it doesn't run a daemon or execute arbitrary Dockerfile instructions.

Bottom line: technically mature, organizationally still Sandbox. Treat the CNCF maturity level as a governance signal, not a stability warning.

Who should use this

  • Teams building Go services/controllers for Kubernetes who want fast, reproducible, minimal (often distroless) images without maintaining Dockerfiles.
  • Platform teams standardizing internal tooling — operators, CLIs, admission webhooks — where build simplicity and image size matter more than build customization.
  • CI pipelines that want to drop Docker-in-Docker or remote Docker daemons entirely, especially in sandboxed or rootless CI environments.
  • Projects already in the Knative/Tekton/Sigstore orbit — ko is a first-class citizen there and integrates cleanly with cosign for signing.

Who should NOT use this

  • Anyone not writing Go. ko is Go-only, full stop — no Python, Node, Java, Rust support.
  • Teams needing custom base images with OS packages, native dependencies (cgo with complex C libs), or non-trivial file system layouts — you'll fight ko's conventions instead of benefiting from them.
  • Organizations with existing Docker-based build pipelines that are working fine — switching build tooling for an already-solved problem is wasted effort.
  • Multi-service monorepos with mixed languages where you want one consistent build tool across the board — you'll still need Docker/Buildpacks/Bazel for the non-Go parts, so the simplification benefit is diluted.

Alternatives

  • Docker/Buildx with a Dockerfile — the default; more control, more maintenance overhead, requires a daemon or BuildKit.
  • Cloud Native Buildpacks (pack CLI, paketo) — language-agnostic, heavier and more opinionated, better fit for polyglot shops.
  • Bazel with rules_oci / rules_go — for teams that already run Bazel and want hermetic, cacheable multi-language builds; steeper learning curve.

Pricing

Fully open source, Apache-2.0. No paid tier, no vendor, no support contract. You run it, you own the toolchain risk.

Frequently asked

What is ko?+
ko is a build tool that turns Go source code into container images without a Dockerfile, a Docker daemon, or a separate build stage in CI. It resolves Go import paths, cross-compiles statically, and constructs an OCI image layer-by-layer directly, then pushes it to a registry.
Who builds ko?+
ko started at Google, targeting the pain of building and deploying Go services to Kubernetes without dragging Docker into every developer's laptop and CI pipeline. It was donated to CNCF and now sits in Sandbox.
Is ko production ready?+
8,461 GitHub stars, active commit history through mid-2026 — not abandoned. 123 contributors — healthy bus factor for a narrow-scope tool. Apache-2.0, standard permissive license, no legal friction. Latest release v0.19.1 — past 1.
Who should use ko?+
Teams building Go services/controllers for Kubernetes who want fast, reproducible, minimal (often distroless) images without maintaining Dockerfiles. Platform teams standardizing internal tooling — operators, CLIs, admission webhooks — where build simplicity and image size matter more than build customization.
Who should not use ko?+
Anyone not writing Go. ko is Go-only, full stop — no Python, Node, Java, Rust support. Teams needing custom base images with OS packages, native dependencies (cgo with complex C libs), or non-trivial file system layouts — you'll fight ko's conventions instead of benefiting from them.
What are the alternatives to ko?+
Docker/Buildx with a Dockerfile — the default; more control, more maintenance overhead, requires a daemon or BuildKit. Cloud Native Buildpacks (pack CLI, paketo) — language-agnostic, heavier and more opinionated, better fit for polyglot shops.
How much does ko cost?+
Fully open source, Apache-2.0. No paid tier, no vendor, no support contract. You run it, you own the toolchain risk.