.dockerignore

Qué es el contexto de build

Al correr docker build -t mi-app ., el . es el contexto: toda la carpeta se empaqueta y se envía al daemon antes de empezar a construir, para que las instrucciones COPY/ADD puedan usarla. Si esa carpeta incluye node_modules (cientos de MBs) o .git (todo el historial), ese peso se envía igual, aunque el Dockerfile nunca los copie a la imagen — build más lento, sin necesidad.

.dockerignore

Un archivo en la raíz del proyecto (mismo lugar que el Dockerfile), con el mismo tipo de patrones que un .gitignore:

.dockerignore

node_modules
.git
.env
*.log
dist
.vscode
Dockerfile
.dockerignore
README.md

Por qué cada línea importa

Entrada	Por qué excluirla
node_modules	Se reinstala dentro del contenedor con npm ci — copiar el local es peso muerto y puede traer binarios nativos compilados para el SO equivocado
.git	Todo el historial del repo, no hace falta para correr la app
.env	Nunca debe terminar dentro de la imagen: las variables secretas no van en su sistema de archivos; se inyectan en tiempo de ejecución con -e o --env-file (ver Variables de entorno)
dist / build	Si la imagen los genera con RUN npm run build, no hace falta copiarlos del host

Efecto en el cache de build

Un .dockerignore bien hecho también ayuda al cache (ver Capas y cache): si node_modules o archivos de log cambian todo el tiempo pero están excluidos, no invalidan capas de COPY . . innecesariamente.

Consideraciones

• Sin .dockerignore, es fácil terminar con secretos (.env, claves privadas) empaquetados dentro de la imagen. Cualquiera con acceso a ella —por ejemplo, desde un registro— podría extraerlos, aunque el Dockerfile nunca los use.
• La sintaxis de patrones es similar a .gitignore pero no 100% idéntica en todos los casos límite — para patrones simples (nombres de carpeta/archivo) se comporta igual.