Source-to-Image (S2I) is a toolkit and workflow for building reproducible container images directly from source code, written in Go and maintained by the OpenShift project. The tool produces ready-to-run images by injecting source code into a container image and allowing the container to prepare that source for execution. Rather than requiring developers to write Dockerfiles, S2I enables the creation of self-assembling builder images that encapsulate build environments, allowing teams to version and control their build setups exactly as they would version runtime environments.

The core workflow of S2I involves creating a container from a builder image, injecting source code into a known directory, running an assemble script that transforms the source into a runnable application, and then committing the resulting container as a new image with an appropriate entrypoint. For dynamic languages like Ruby, the build-time and runtime environments are typically identical, so a single builder image containing all necessary dependencies can be used directly. For compiled languages such as Java, C++, or Go, S2I supports multi-stage build processes where compilation happens in one builder image, artifacts are extracted, and then injected into a leaner runtime image, keeping production deployments slim while maintaining consistency between build and runtime environments.

Builder images in S2I require specific scripts to function: an assemble script that builds or deploys the source, a run script that executes the assembled artifacts, and optional save-artifacts and usage scripts. The build workflow is controlled through configuration files like .s2iignore for filtering source files and .s2i/environment for setting build-time environment variables. S2I also supports ONBUILD strategy for official Dockerfile language stack images and enables incremental builds through the save-artifacts mechanism, allowing previous build artifacts to be reused in subsequent builds to accelerate the build process.

The project emphasizes four primary goals: reproducibility through tightly versioned build environments encapsulated in container images, flexibility by allowing any Linux-compatible build system to run inside containers, speed by representing applications in single image layers rather than multiple Dockerfile layers, and security by controlling permissions and privileges available to builder images during the build process. This approach contrasts with traditional Dockerfile builds, which typically run without normal operational controls and often execute as root.

According to GitGenius activity tracking, the repository shows relatively slow issue and pull request response latency, with a median response time of 1511.3 hours and a mean of 8229.2 hours across tracked items. The most frequently applied issue labels are lifecycle/frozen and lifecycle/rotten, indicating that many issues have been inactive for extended periods. Primary contributors tracked by GitGenius include adambkaplan with 8 events, jmtd with 3 events, and erdii with 2 events. The repository shares contributors with related projects including tektoncd/pipeline, cekit/cekit, and tektoncd/cli, reflecting S2I's integration within the broader Kubernetes and container ecosystem. The project is classified across multiple domains including containerization, image building, build automation, reproducible builds, and CI/CD workflows, positioning it as a foundational tool for container-native application development and deployment pipelines.