FROM es la instrucción que selecciona la imagen base de una etapa de construcción. A partir de ella, las instrucciones siguientes añaden configuración, ejecutan pasos y construyen el sistema de archivos de esa etapa.
Un Dockerfile puede tener varias instrucciones FROM. Cada una inicia una etapa nueva; la etapa final es la imagen que se construye por defecto. Nombrar las etapas permite copiar artefactos entre ellas sin llevar herramientas de compilación al runtime.
👉 Y recuerda, si quieres aprender más de Linux, visita el curso de Linux gratis.
🐳 Si quieres aprender más de Docker, visita el curso de Docker gratis.
Qué hace FROM en Dockerfile
FROM descarga o reutiliza una imagen como punto de partida y comienza una etapa. Define el sistema de archivos inicial y parte de la configuración heredada por las instrucciones posteriores. La imagen debe existir localmente o poder obtenerse del registro indicado.
Un Dockerfile debe empezar por FROM, salvo que antes incluya comentarios, directivas del parser o argumentos globales ARG usados para parametrizar la propia imagen base. Cada FROM posterior reinicia el contexto de la etapa: no conserva automáticamente los cambios hechos en una etapa anterior.
Sintaxis y formas habituales de FROM
| Forma | Qué establece | Cuándo usarla |
|---|---|---|
| FROM imagen:etiqueta | La base y una referencia legible de versión. | Elegir una versión mantenida de una imagen. |
| FROM imagen AS nombre | La base y un alias para la etapa. | Referirse después a esa etapa con COPY –from o usarla como base de otra. |
| FROM –platform=plataforma imagen | La plataforma de la base de esa etapa. | Controlar arquitectura o sistema objetivo cuando el build lo necesita. |
| FROM imagen@sha256:digest | La base exacta identificada por su digest. | Reproducir qué artefacto se utilizó y actualizarlo de forma controlada. |
| FROM scratch | Una etapa sin archivos de una imagen base. | Crear imágenes mínimas cuando la aplicación puede ejecutarse sin dependencias adicionales. |
Las etiquetas como 3.12 o stable-alpine hacen la referencia más comprensible, pero su contenido puede cambiar cuando se publica una actualización. Un digest fija el artefacto exacto, a costa de que el equipo tenga que revisar y actualizar esa referencia para recibir correcciones.
Ejemplo: construir una imagen a partir de una base
Este ejemplo parte de una imagen de Python, establece el directorio de trabajo, instala las dependencias declaradas y copia el código. La base elegida debe ser compatible con las bibliotecas de la aplicación y tener un ciclo de mantenimiento que puedas seguir.
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY src/ ./src/
CMD ["python", "src/app.py"]requirements.txt y src/app.py deben existir en el contexto de construcción. El ejemplo instala dependencias durante el build; la ejecución del contenedor usará el comando configurado en CMD. Revisa la versión de Python y las bibliotecas nativas que necesita tu proyecto.
Cómo inicia una etapa multi-stage
Cuando un Dockerfile contiene más de un FROM, cada uno crea una etapa independiente. Puedes darles un alias con AS y usar COPY –from para pasar archivos desde una etapa anterior. La imagen final solo necesita recibir los artefactos y recursos que requiere el servicio en ejecución.
FROM node:22-bookworm-slim AS build
WORKDIR /src
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM nginx:stable-alpine AS runtime
COPY --from=build /src/dist/ /usr/share/nginx/html/Aquí npm y los archivos de desarrollo permanecen en la etapa build. El runtime de Nginx recibe la carpeta dist generada por el build. El ejemplo supone que el proyecto produce esa carpeta; si tu framework usa otra salida, adapta la ruta del origen.
Cómo elegir una imagen base
Elige una imagen cuyo publicador y política de soporte puedas verificar. Comprueba que incluya las bibliotecas que necesita la aplicación, que sea compatible con la arquitectura de destino y que reciba actualizaciones. Una variante pequeña no siempre es la adecuada si obliga a añadir paquetes o dificulta el mantenimiento.
Evita usar una etiqueta genérica sin control en despliegues reproducibles. Si necesitas una referencia inmutable, registra el digest; después incorpora su actualización al proceso habitual de análisis y pruebas. El digest identifica exactamente la imagen, pero no garantiza por sí mismo que sea segura o que siga mantenida.
Errores comunes al utilizar FROM
- Creer que una nueva etapa hereda los archivos previos: cada FROM inicia un sistema de archivos independiente; transfiere lo necesario con COPY –from.
- Elegir solo por tamaño: confirma compatibilidad, soporte y dependencias del runtime.
- Fijar un digest y olvidarlo: revisa las actualizaciones para incorporar correcciones y cambios de soporte.
- Usar scratch sin comprobar dependencias: verifica que el binario y los recursos necesarios puedan ejecutarse sin un sistema de archivos base.
Lecciones relacionadas del curso
- Cómo elegir una imagen base Docker segura: evalúa origen, mantenimiento y compatibilidad.
- Qué es un multi-stage build: separa compilación y runtime con varias etapas FROM.
- Cómo reducir el tamaño de una imagen Docker: revisa qué contenido queda en la etapa final.
- Buenas prácticas y errores comunes al construir imágenes: repasa fallos habituales de diseño y mantenimiento.
Documentación oficial y recursos
- Docker Docs: instrucción FROM.
- Docker Docs: builds multi-stage.
- Docker Docs: buenas prácticas de construcción.
FROM determina con qué base empieza cada etapa. Una selección justificada, unas etapas bien delimitadas y una política de actualización convierten esa elección en una parte comprensible y mantenible del Dockerfile.
