content/docs/for-platform-operators/concepts/lifecycle/_index.md
+++ title="What is the lifecycle?" weight=3 include_summaries=true +++
The lifecycle orchestrates buildpacks, then assembles the resulting artifacts into an OCI image.
It does its work in a series of distinct "phases".
An image build requires 5 lifecycle phases, as shown below:
Note: when talking about lifecycle phases you'll sometimes see nouns like
analyzeror/cnb/lifecycle/analyzerand you'll sometimes see verbs likeanalyzeoranalyze phase.
These are all more-or-less interchangeable: the nouns refer to the
lifecyclebinary and the verbs refer to the work that thelifecycleperforms.
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.
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.