In this Video

In this latest OpenShift Commons Briefing, Ben Parees, lead developer at Red Hat on Source-to-Image (S2I) project, explains how Source-to-Image works and gives a deep technical into the anatomy of S2I Builder Images along with a step-by-step demonstrations on a number of the different workflows for creating enterprise-ready reusable images.

What is Source-to-Image?

S2I Developer WorkFlow

Source-to-Image (S2I) is a toolkit and workflow for building reproducible Docker images from source code.
S2I produces ready-to-run images by injecting source code into a Docker container and letting the container prepare that source code for execution.
By creating self-assembling builder images, you can version and control your build environments exactly like you use Docker images to version your runtime environments.

Why does Source to Image Matter?

The Source-to-Image project was started to make it easier to take source code and combine it with an image that contains both a build and runtime environment for that source code (called a “builder image”) .
Having a strong separation between source code (or even binary artifacts like WARs or EARs in Java) and the runtime environment in the Docker image helps migrate your code between runtime environments like Tomcat and other JEE servers, across major versions of a runtime like Ruby 1.9 and Ruby 2.0, or even across operating system versions like CentOS and Red Hat Enterprise Linux.

Source to Image Project's Design Goals


Allow build environments to be tightly versioned by encapsulating them within a Docker image and defining a simple interface (injected source code) for callers. Reproducible builds are a key requirement to enabling security updates and continuous integration in containerized infrastructure, and builder images help ensure repeatability as well as the ability to swap runtimes.


Any existing build system that can run on Linux can be run inside of a container, and each individual builder can also be part of a larger pipeline. In addition, the scripts that process the application source code can be injected into the builder image, allowing authors to adapt existing images to enable source handling.


Instead of building multiple layers in a single Dockerfile, S2I encourages authors to represent an application in a single image layer. This saves time during creation and deployment, and allows for better control over the output of the final image.


Dockerfiles are run without many of the normal operational controls of containers, usually running as root and having access to the container network. S2I can be used to control what permissions and privileges are available to the builder image since the build is launched in a single container. In concert with platforms like OpenShift, source-to-image can enable admins to tightly control what privileges developers have at build time.

Learn more about building your own images.

OpenShift Commons Briefings Playlist

You can find the entire backlog of OpenShift Commons Briefings on this Youtube Playlist of all previously recorded briefings on YouTube.

Don't forget to leave your feedback and suggestions for each video or in the comments section below. This will be incredibly important to shape the content of future briefings sessions and provide content that satisfies the entire OpenShift Community.

About OpenShift Commons

OpenShift Commons is the place for organizations that are part of the OpenShift community to connect with peers and other related open source technology communities to communicate and collaborate across all OpenShift projects and stakeholders.

The Commons' goal is to foster collaboration and communication between OpenShift stakeholders to drive success for all its members.

As a result, the OpenShift Commons expands & facilitates points of connection between members for sharing their knowledge and experience. Consequently, the OpenShift Commons help to drive success for the platform and for all the participants: customers, users, partners, and contributors.

Join OpenShift Commons today