✦ For everyone, free.

Practical knowledge for real and everyday life

Home

4.2.5.1 RUN Package Install

A focused guide to RUN Package Install, connecting core concepts with practical Docker and container operations.

Using RUN for package installation is one of the most common applications of the instruction, invoking a package manager to install the system-level or language-level dependencies an application needs, with careful structuring to minimize both layer count and final image size.

Installing System Packages

System package installation typically combines updating the package index, installing the needed packages, and cleaning up afterward, all within a single RUN instruction.

RUN apt-get update && apt-get install -y --no-install-recommends curl libpq5 \
    && rm -rf /var/lib/apt/lists/*

Combining these steps into one instruction ensures the resulting layer reflects only the net effect — installed packages without the now-unnecessary package index cache.

Installing Language-Specific Packages

Language ecosystems have their own package managers, typically invoked through RUN once a dependency manifest has already been copied into the build context.

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

Disabling the package manager's own download cache, where supported, avoids leaving unnecessary cached package data inside the resulting layer.

Avoiding Unnecessary Recommended Packages

Many package managers install additional, often unnecessary packages by default alongside what was explicitly requested; disabling this behavior keeps the installation closer to exactly what is actually needed.

RUN apt-get install -y --no-install-recommends curl
Pinning Specific Package Versions

For more reproducible builds, pinning specific package versions rather than always installing whatever is currently the latest available avoids unexpected changes in behavior caused by an upstream package update.

RUN apt-get install -y curl=7.88.1-10
Why Careful Package Installation Matters

Because package installation steps are often the largest single contributor to both build time and final image size, structuring them carefully — combining related steps, avoiding unnecessary packages, cleaning up caches within the same layer — has a disproportionately large effect on overall image quality compared to most other parts of a typical Dockerfile.