Plan your image strategy

To secure production deployments and ensure consistent builds, identify the appropriate images and tags for your application. Proper planning maintains a clear separation between development tools and minimal, hardened production environments.

Red Hat Hardened Images tags

To manage the balance between receiving security updates and maintaining version stability, select the appropriate tag or digest. Use these variants to control the content and lifecycle of your environment.

Use the tags in the following table to control when your environment receives updates:

Table 1. Image tag types
Tag type	Example	Intent and lifecycle
Latest	`:latest`	Refers to the most recent release. Use this tag to test new features, but do not use it in production to prevent unexpected breaking changes.
Major version	`:3`	Tracks the highest minor release of a major version. For example, if version 3.13 and 3.14 of the image are available, `:3` refers to 3.14. Use major version tags in development and CI to automatically receive new features and fixes.
Specific version	`:3.14`	Pins the image to a specific minor release. Use version-specific tags for mission-critical applications that require strict compatibility testing before any change.
Digest	`sha256-<checksum>`	Identifies exactly one image by its immutable SHA-256 hash. Use it in production for absolute reproducibility and to ensure the image target never changes.

For further details on deciding which tags to use, see the This content is not included.How to name, version, and reference container images article.

The builder and runtime models

The builder and runtime models separate development tools from the minimal environment required to run applications. This architectural split reduces the attack surface of your production containers.

Use the following multi-stage build workflow:

The Build Stage: A builder image serves as the initial environment for installing dependencies and compiling code.
- Builder variant (<tag>-builder):
  Includes the dnf package manager and the bash shell. For example, you can use dnf to install additional dependencies.
  Example: registry.access.redhat.com/hi/python:latest-builder
The Runtime Stage: The process completes by migrating only the resulting application binary into a runtime image.
- Standard runtime variant (<tag> without a suffix):
  The most minimal runtime image without a package manager, shell, or other unnecessary components.
  Example: registry.access.redhat.com/hi/python:latest
- Federal Information Processing Standard (FIPS) runtime variant (<tag>-fips):
  A minimal production image that is optimized to run on hosts that operate in Federal Information Processing Standard (FIPS) mode. FIPS images also have a <tag>-fips-builder variant`, similar to the normal builder variant.
  Not all images have a FIPS variant.
  Example: registry.access.redhat.com/hi/python:latest-fips

Note:

Depending on the image you use, there can be more runtime and builder variants.

Key benefits of a multi-stage build workflow:

Hardening: By using a minimal image, without a package manager, shell, and compilers, you limit the tools available to a potential attacker.
Efficiency: Runtime images are significantly smaller, that leads to faster image pulls and lower storage costs.
Maintainability: You can update the build tools in your builder image without affecting the stable runtime environment of your application.
Compliance: The FIPS variant ensures your application uses validated cryptographic modules in restricted environments.