ko vs Source-to-Image
ko
ko.buildSource-to-Image
github.comSide by side
| Figure | ko | Source-to-Image |
|---|---|---|
| Price from | Free | Free |
| Free plan | Yes | Yes |
| Free trial | — | — |
| Open source | — | Yes |
| Windows | Yes | Yes |
| macOS | Yes | Yes |
| Linux | Yes | Yes |
| Self-hosted | — | Yes |
| Plans published | 1 | 1 |
| Spec score · Container Build Tools | 8.3 (#8) | 8.1 (#12) |
| Integrations | ko provides a Terraform provider for using image builds in Infrastructure-as-Code workflows. | The README documents use with Docker and gives examples using OpenShift, UBI, Ruby, and WildFly images. |
| Purpose | ko is a simple, fast container image builder for Go applications. | Source-to-Image is a toolkit and workflow for building reproducible container images from source code. |
Plans
In their own words
ko
ko is an open-source builder for container images of Go applications. It runs `go build` locally, so Docker does not need to be installed. The project positions it for a single Go application with few operating-system base-image dependencies, such as one without cgo or OS package requirements. Builds can target all platforms supported by the configured base image or selected platforms such as linux/amd64 and linux/arm64. For Kubernetes, `ko resolve` builds images for `ko://` references in YAML and replaces those references with image references; `ko apply` can apply the resolved configuration. ko reuses the normal Go build cache and avoids pushing image blobs already present in the remote registry. It generates and uploads SPDX-format SBOMs by default, with an option to disable this. Registry credentials can come from Docker configuration, with built-in environment credential support for Google, Amazon, Azure, and GitHub container registries. A Terraform provider supports Infrastructure-as-Code workflows. ko supports Go applications only and defaults to CGO_ENABLED=0. Windows container image support is experimental and requires a Windows base image.
Source-to-Image
Source-to-Image is a free, Apache-2.0 toolkit for building reproducible container images from source code. It places source in a builder image, lets that container prepare the application, and outputs a ready-to-run image. A documented workflow can build from a Git repository without a Dockerfile. Builder images may provide assemble and run scripts, plus optional scripts for saving artifacts and explaining usage. Compatible builders can reuse artifacts from an earlier output when incremental settings and scripts are supplied. A .s2iignore file filters source files and directories, while .s2i/environment defines build variables that also appear in the output image. S2I can use an OnBuild strategy with images containing Dockerfile ONBUILD instructions. Examples cover Docker, OpenShift, UBI, Ruby, and WildFly. It runs on Linux, macOS, and Windows, with Docker 1.6+ and Go 1.7.1+ listed as dependencies.