The lifecycle orchestrates buildpacks, then assembles the resulting artifacts into an OCI image. It does its work in a series of distinct “phases”.

Build Phases

An image build requires 5 lifecycle phases, as shown below:

Note: when talking about lifecycle phases you’ll sometimes see nouns like analyzer or /cnb/lifecycle/analyzer and you’ll sometimes see verbs like analyze or analyze phase.

These are all more-or-less interchangeable: the nouns refer to the lifecycle binary and the verbs refer to the work that the lifecycle performs.

The lifecycle must be run in a containerized environment (such as a Docker container or CI/CD system).

The analyzer, restorer, and exporter (shown in pink above) require access to an image repository - either an OCI registry or Docker-compliant daemon (such as Docker or Podman) in order to do their work.

This means that either registry credentials or a Docker socket must be available in the container where the lifecycle phase is running. For security hardening, these phases run in separate containers to avoid exposing sensitive data to buildpacks.

The detector and builder (shown in purple above) invoke buildpacks to do the work of determining which buildpacks are needed and transforming application source code into runnable artifacts (the real work of buildpacks!). For security hardening, both the lifecycle and buildpacks run as non-root users when doing this work.

When a builder is trusted, all 5 lifecycle phases can be run in the same container, and in this case the creator binary is used to run all 5 lifecycle phases with a single command invocation.

To coordinate between phases, the lifecycle outputs a series of configuration files which are part of the Platform API specification. For the most part, platform operators do not need to be concerned with these files unless they are designing their own platform.

Diving Deeper

Read on to learn more about each lifecycle phase, including phases not shown above. These include phases relating to starting or rebasing the application, or extending base images used during the build.

Analyze

The analyzer restores files that buildpacks may use to optimize the build and export phases.

Detect

The detector finds an ordered group of buildpacks to use during the build phase.

Restore

The restorer copies layers from the cache into the build container.

Build

The builder transforms application source code into runnable artifacts that can be packaged into a container.

Export

The exporter creates the final OCI image and updates the image config with new metadata to reflect the latest changes.

Create

The creator runs analyze, detect, restore, build, and export in a single command.

Launch

The launcher is the entrypoint for the final OCI image, responsible for launching application processes.

Rebase

The rebaser places application layers atop a new version of the runtime base image.

Extend

The extender applies Dockerfiles output by image extensions to the build or runtime base image.

---