KIWI NG vs Source-to-Image
KIWI NG
osinside.github.ioSource-to-Image
github.comSide by side
| Figure | KIWI NG | Source-to-Image |
|---|---|---|
| Price from | Free | Free |
| Free plan | Yes | Yes |
| Free trial | — | — |
| Open source | — | Yes |
| Windows | — | Yes |
| macOS | — | Yes |
| Linux | Yes | Yes |
| Self-hosted | Yes | Yes |
| Plans published | 1 | 1 |
| Spec score · Container Build Tools | 8.2 (#10) | 8.1 (#12) |
| License | The source repository identifies the project license as GPL-3.0. | The repository is released under the Apache License 2.0. |
| Purpose | KIWI NG is a command-line image builder that creates bootable, reproducible Linux images for virtual machines, cloud platforms, removable media, containers, and specialized deployment targets. | Source-to-Image is a toolkit and workflow for building reproducible container images from source code. |
Plans
In their own words
KIWI NG
KIWI NG is a free, daemonless command-line image builder for Linux. It turns versioned image descriptions and package repositories into bootable, reproducible artifacts. A prepared root tree can produce disk images, ISO files, or containers for virtual machines, cloud platforms, removable media, and specialized targets. Descriptions define metadata, repositories, packages, users, storage, target configuration, and image types, using config.xml or a .kiwi file. Overlays, archives, and scripts add customization. Documented package managers include apk, apt, dnf4, dnf5, microdnf, pacman, and zypper. Supported distributions include Fedora, CentOS Stream, openSUSE, Ubuntu, Debian, and Arch Linux. Builds support multiple architectures and a local cache backend. Installation is available through distribution packages, Open Build Service, or pip. A recent Linux host, Python 3.9 or newer, Git, and at least 15 GB recommended free disk space are required. QEMU can optionally boot and inspect outputs; GPL-3.0 governs the source.
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.