Imagen Docker (capas/tamaño)🌎 Actualizado abril de 2026
Esta calculadora te permite estimar el tamaño total de una imagen Docker sumando el peso de la imagen base y el de las dependencias o capas adicionales que instalás durante el build. En Docker, cada instrucción RUN, COPY o ADD en el Dockerfile genera una capa inmutable que se apila sobre la anterior. El tamaño final de la imagen es la suma del peso comprimido de todas esas capas. Elegir correctamente la imagen base (Alpine ~5 MB, Debian Slim ~80 MB, Ubuntu ~77 MB, Node oficial ~900 MB) puede significar la diferencia entre desplegar contenedores en segundos o en minutos, con un impacto directo en costos de almacenamiento en registros como Docker Hub, Amazon ECR o GitHub Container Registry.
Cuándo usar esta calculadora
- Estimá cuánto espacio va a ocupar tu imagen antes de hacer el push a Docker Hub o Amazon ECR, para planificar costos de almacenamiento.
- Compará distintas imágenes base (Alpine vs. Debian Slim vs. Ubuntu) para elegir la más liviana que cubra tus necesidades de runtime.
- Calculá el ahorro en tamaño al migrar de una imagen monolítica a un multi-stage build, separando la etapa de compilación de la de producción.
- Estimá el tiempo de pull de una imagen en un pipeline de CI/CD según su peso total, para identificar cuellos de botella en deployments automáticos.
- Planificá la capacidad de almacenamiento en un registro privado (Harbor, Nexus, ECR) según la cantidad de imágenes y sus tamaños proyectados.
Ejemplo de cálculo
- Alpine + 50MB
- ~55 MB
Cómo funciona
4 min de lecturaCómo se calcula
El tamaño de una imagen Docker es la suma de todas sus capas (layers). Cada capa es inmutable y se identifica por su hash SHA-256. El tamaño que muestra docker images es el tamaño descomprimido (en disco), mientras que el tamaño de transferencia (push/pull) es el comprimido (aprox. 40-60% del original).
Tamaño total (disco) = Σ Peso de cada capa
Tamaño transferencia ≈ Tamaño total × 0.45 (ratio de compresión típico gzip)
Capas = Base layer + RUN layer 1 + RUN layer 2 + ... + COPY layer NCon multi-stage build:
Tamaño final = Solo capas del stage final (sin herramientas de compilación)
Ahorro = Tamaño single-stage − Tamaño multi-stageTabla de referencia
| Imagen base | Tamaño disco | Tamaño comprimido | Sistema base | Uso típico |
|---|---|---|---|---|
scratch | 0 MB | 0 MB | Vacío | Binarios Go estáticos |
alpine:3.19 | ~7 MB | ~3 MB | Alpine Linux / musl | Microservicios, CLIs |
debian:12-slim | ~80 MB | ~30 MB | Debian / glibc | Apps Python, Ruby |
ubuntu:24.04 | ~77 MB | ~29 MB | Ubuntu / glibc | General purpose |
node:20-alpine | ~130 MB | ~51 MB | Alpine + Node.js | Apps Node.js livianas |
node:20 | ~1.1 GB | ~430 MB | Debian + Node.js | Node.js con todas las libs |
python:3.12-slim | ~130 MB | ~50 MB | Debian Slim + Python | Apps Python |
python:3.12 | ~1.0 GB | ~390 MB | Debian + Python | Python con compiladores |
openjdk:21-slim | ~250 MB | ~95 MB | Debian Slim + JDK | Apps Java |
golang:1.22-alpine | ~250 MB | ~100 MB | Alpine + Go toolchain | Solo para build stage |
Casos típicos
Caso 1: API Node.js sin optimización vs. con Alpine
Sin optimizar:
node:20 → 1.1 GBnpm install (producción) → +150 MBCon Alpine + multi-stage:
node:20-alpine → 130 MB + deps dev → descartadonode:20-alpine → 130 MB + solo node_modules prod (50 MB) + código (5 MB)---
Caso 2: Binario Go con scratch
dockerfile
# Stage 1: compilación
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o api .
# Stage 2: imagen final
FROM scratch
COPY --from=builder /app/api /api
ENTRYPOINT ["/api"]---
Caso 3: App Python con dependencias ML (sin optimizar)
python:3.12 → 1.0 GBpip install pandas numpy scikit-learn → +600 MBpython:3.12-slim + solo dependencias necesarias → ~550 MBErrores comunes
1. Usar la imagen base completa cuando existe -slim o -alpine: node:20 ocupa 1.1 GB vs. node:20-alpine con 130 MB. Siempre evaluá si la versión slim/alpine cubre tu caso.
2. Instalar dependencias de build en la imagen final: Herramientas como gcc, make, git o build-essential son necesarias para compilar, pero no para correr la app. Usá multi-stage builds para descartarlas.
3. Cada RUN que instala Y borra paquetes en comandos separados: Si hacés RUN apt-get install -y curl y luego en otro RUN hacés rm -rf /var/lib/apt/lists/*, la primera capa YA guardó el caché de apt. Todo debe ir en un solo RUN encadenado con &&.
4. Copiar todo el contexto con COPY . . sin .dockerignore: Incluir carpetas como node_modules/, .git/, dist/ o archivos de log puede agregar cientos de MB innecesarios. Siempre definí un archivo .dockerignore.
5. No usar --no-cache o --no-install-recommends en apt: apt-get install -y paquete sin --no-install-recommends instala dependencias recomendadas que pueden sumar 50-200 MB extras. Usá apt-get install -y --no-install-recommends paquete && rm -rf /var/lib/apt/lists/*.
6. Ignorar el orden de las capas para aprovechar la caché: Docker cachea por capa. Si ponés COPY . . antes de RUN npm install, cualquier cambio en el código invalida la caché de npm. Lo correcto es: COPY package*.json ./ → RUN npm install → COPY . ..
Calculadoras relacionadas
Preguntas frecuentes
¿Cuál es la diferencia entre el tamaño en disco y el tamaño de transferencia de una imagen Docker?
El tamaño que muestra docker images es el tamaño descomprimido en disco, que es la suma de todas las capas extraídas. El tamaño de transferencia (lo que se descarga al hacer docker pull) es el tamaño comprimido con gzip, que típicamente representa entre el 40% y el 60% del tamaño en disco. Por ejemplo, una imagen de 500 MB en disco generalmente pesa unos 200-225 MB en el registro.
¿Por qué Alpine Linux es tan popular como imagen base para producción?
Alpine Linux usa musl libc en lugar de glibc y el shell BusyBox, lo que le permite tener un tamaño base de apenas ~5-7 MB vs. ~77-80 MB de Ubuntu o Debian. Además, su gestor de paquetes apk es muy eficiente. La contrapartida es que algunas librerías compiladas para glibc no funcionan directamente en Alpine, por lo que hay que verificar compatibilidad, especialmente en aplicaciones Python con extensiones C o Java.
¿Qué es un multi-stage build y cuánto puede reducir el tamaño de una imagen?
Un multi-stage build usa múltiples instrucciones FROM en un solo Dockerfile: las etapas anteriores se usan para compilar y las finales solo copian los artefactos necesarios. En la práctica, puede reducir el tamaño entre un 70% y 95%. Un ejemplo típico: una app Go pasa de ~800 MB (imagen con toolchain) a ~10 MB (binario estático en scratch). Para Node.js, de ~1.2 GB a ~180 MB.
¿Cómo puedo ver el peso exacto de cada capa de mi imagen Docker?
Usá el comando docker history <imagen> que muestra el tamaño de cada capa y la instrucción que la creó. Para un análisis más visual y detallado, la herramienta open-source Dive (github.com/wagoodman/dive) permite inspeccionar capa por capa, ver qué archivos agrega cada instrucción y detectar desperdicios. También podés usar docker inspect <imagen> para ver los metadatos completos en JSON.
¿Las capas se comparten entre imágenes en el mismo host Docker?
Sí, esa es una de las grandes ventajas del sistema de capas. Si tenés 5 imágenes basadas en node:20-alpine, la capa de Alpine y la de Node se almacenan una sola vez en el sistema de archivos del host (usando overlay2 por defecto). Docker identifica cada capa por su hash SHA-256, y si dos imágenes comparten una capa con el mismo hash, no la duplica. Esto ahorra espacio significativo en servidores con muchos contenedores.
¿Cuánto espacio libre necesito tener en el host para correr Docker sin problemas?
Docker recomienda al menos 10 GB de espacio libre para un uso básico. En producción, el espacio depende de cuántas imágenes y contenedores mantenés activos. Docker almacena todo en /var/lib/docker por defecto. Podés limpiar recursos no usados con docker system prune -a (elimina imágenes sin usar, contenedores detenidos, redes y caché de build). Ejecutalo periódicamente para recuperar espacio, especialmente en pipelines de CI/CD.
¿Existe un límite de capas en una imagen Docker?
Docker con el driver de almacenamiento overlay2 (el default en Linux moderno) soporta hasta 128 capas por imagen. En la práctica rara vez se llega a ese límite, pero es una razón más para consolidar comandos RUN con && en lugar de usar un RUN separado por cada comando. Cada RUN, COPY y ADD crea una nueva capa, así que un Dockerfile mal estructurado puede acumular decenas de capas innecesarias.
¿Cómo afecta el tamaño de la imagen al tiempo de deployment en Kubernetes o en servicios cloud?
Directamente: una imagen de 1 GB tarda entre 30 segundos y 3 minutos en descargarse según el ancho de banda del nodo (típicamente 1-10 Gbps en cloud). Esto impacta en el tiempo de arranque de pods y en la velocidad de autoscaling. En servicios como AWS ECS o GKE, imágenes más pequeñas también reducen costos de transferencia de datos desde ECR o GCR. La recomendación general es apuntar a imágenes de producción por debajo de los 200 MB siempre que sea posible.
Fuentes y referencias
Metodología y confianza
Contenido revisado por el equipo editorial de Hacé Cuentas, con apego a nuestra política editorial y metodología de cálculo.
Última revisión: 18 de abril de 2026. Los parámetros fiscales, legales y datos se verifican periódicamente con las fuentes citadas.
Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos. Leé nuestra política de privacidad.
Resultados orientativos. Para decisiones financieras, médicas o legales críticas, consultá con un profesional.