Calculadora de tamaño de imagen Docker (capas + MB)
Calculá el tamaño total de tu imagen Docker eligiendo imagen base (Alpine, Debian Slim, Ubuntu, Distroless) y sumando las capas de dependencias. Sabé cuánto va a pesar antes del docker push.
Calculadora Gratis · Privada
Tus últimos cálculos
Revisado por: Martín Rodríguez (política editorial ) · Última revisión:
Resultado
Tamaño total estimado
130 MB — imagen liviana, apta para deploy directo sin multi-stage
Evaluación
Detalle
Ver cálculo paso a paso
¿Te sirvió este cálculo?
¡Gracias! Tu feedback nos ayuda a mejorar.
Tu resultado
—
Cuando hacés
docker push y tardás 4 minutos en subir una imagen que podría pesar 10 veces menos, el problema no es tu conexión: es cómo construiste la imagen. Esta calculadora te ayuda a estimar el tamaño total de una imagen Docker sumando el peso de la imagen base más las dependencias y capas adicionales que instalás durante el build, antes de que pierdas tiempo y plata en registros como Docker Hub, Amazon ECR o GitHub Container Registry.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 es la suma comprimida de todas esas capas. El problema es que muchos equipos arrancan con la imagen oficial de Node (~900 MB) o Python (~900 MB) sin preguntarse si realmente necesitan todo lo que trae, y terminan con pipelines de CI/CD lentos y facturas de almacenamiento más altas de lo necesario.
La elección de la imagen base es la decisión más impactante: Alpine Linux pesa ~5 MB, Debian Slim ~80 MB, Ubuntu ~77 MB, la imagen oficial de Node ~900 MB y la de Python ~920 MB. Sumale capas mal consolidadas (un RUN apt-get install por línea en vez de uno solo con &&) y podés duplicar o triplicar el tamaño sin notarlo.
Esta calculadora te da un número concreto para comparar escenarios: ¿cuánto bajás si migrás a Alpine? ¿Cuánto ahorrás con un multi-stage build? ¿Vale la pena usar scratch o distroless para tu binario Go?
Cuándo usar esta calculadora
- Un equipo de desarrollo tiene una imagen Node.js basada en
node:20que pesa 920 MB. Estimando base Alpine (5 MB) + Node compilado (45 MB) + dependencias npm (80 MB), proyectan bajar a ~130 MB: un 86% menos de almacenamiento en ECR y pull times de 8 seg en vez de 55 seg. - Una startup que deployea en AWS ECS tiene 50 versiones de su imagen en ECR a 800 MB cada una: 40 GB de storage a USD 0,10/GB/mes = USD 4/mes. Migrando a imágenes de 150 MB, el costo baja a USD 0,75/mes.
- Un pipeline de GitHub Actions tarda 4 minutos en hacer pull de la imagen base antes de correr tests. Calculando que Alpine + dependencias pesaría 120 MB en vez de 900 MB, el equipo proyecta reducir ese paso a menos de 40 segundos.
- Un SRE planifica capacidad para un registro privado Harbor que va a alojar 200 imágenes de microservicios. Estimando promedio de 300 MB por imagen, calcula 60 GB de storage necesario y elige el tier de almacenamiento adecuado antes de provisionar.
- Un dev está migrando una app Go de una imagen
golang:1.22(~800 MB) a un multi-stage build con imagen finalscratch(0 MB base + binario estático ~12 MB). La calculadora le confirma que el resultado final sería ~12 MB, validando que el esfuerzo de migración tiene sentido. - Un equipo de ML usa una imagen Python con TensorFlow que pesa 3,2 GB. Calculando base slim (80 MB) + TensorFlow CPU (600 MB) + deps adicionales (200 MB), estiman que la versión optimizada pesaría ~880 MB: 72% menos, lo que cambia radicalmente sus costos de transferencia en GCR.
- Un arquitecto de plataforma evalúa si conviene usar
node:20-alpine(~170 MB) onode:20-slim(~240 MB) para 80 microservicios en un clúster Kubernetes. La diferencia de 70 MB por imagen, multiplicada por 80 servicios y 10 versiones en caché por nodo, representa 56 GB de disco por nodo. - Un freelancer que trabaja para un cliente europeo necesita justificar el tiempo de refactoring del Dockerfile. Muestra que la imagen actual pesa 1,1 GB y la proyectada pesa 95 MB, traduciendo eso en USD 12/mes de ahorro en Docker Hub Pro y pipelines 3x más rápidos.
Peso de imágenes base Docker más comunes
| Imagen base | Tamaño en disco | Tamaño comprimido | Uso típico |
|---|---|---|---|
| scratch | 0 MB | 0 MB | Binarios Go estáticos |
| distroless/static | ~2 MB | ~1 MB | Binarios estáticos Go/Rust |
| alpine:3.19 | ~5–7 MB | ~3 MB | Microservicios, CLIs |
| distroless/nodejs20 | ~165 MB | ~65 MB | Node.js seguro en producción |
| debian:12-slim | ~80 MB | ~30 MB | Apps Python, Ruby |
| ubuntu:24.04 | ~77 MB | ~29 MB | General purpose |
| node:20-alpine | ~130 MB | ~51 MB | Apps Node.js livianas |
| node:20-slim | ~240 MB | ~90 MB | Node.js con más compatibilidad |
| node:20 | ~1.100 MB | ~430 MB | Node.js con todas las libs |
| python:3.12-slim | ~130 MB | ~50 MB | Apps Python |
| python:3.12 | ~1.000 MB | ~390 MB | Python con compiladores |
| golang:1.22-alpine | ~250 MB | ~100 MB | Solo para build stage |
Fuente: Docker Documentation — Best practices for writing Dockerfiles (2026). Tamaños aproximados; pueden variar con cada release.
Cómo funciona
Cómo se calcula el tamaño de una imagen Docker
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) = Imagen base + Σ capas adicionales
Tamaño transferencia ≈ Tamaño total × 0,45 (ratio de compresión típico gzip)Con 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: pesos de imágenes base comunes
| Imagen base | Tamaño en disco | Tamaño comprimido | Sistema base | Uso típico |
|---|---|---|---|---|
scratch | 0 MB | 0 MB | Vacío | Binarios Go estáticos |
alpine:3.19 | ~5–7 MB | ~3 MB | Alpine Linux / musl | Microservicios, CLIs |
distroless/static | ~2 MB | ~1 MB | Sin OS shell | Binarios estáticos Go/Rust |
distroless/nodejs20 | ~165 MB | ~65 MB | Sin shell + Node.js | Node.js seguro en producción |
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-slim | ~240 MB | ~90 MB | Debian Slim + Node | Node.js con más compatibilidad |
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 | Solo para build stage |
Tabla de ejemplos de tamaño final por tipo de app
| App / stack | Imagen base | Deps agregadas | Total estimado | Multi-stage posible |
|---|---|---|---|---|
| API Go (binario estático) | scratch | ~12 MB | ~12 MB | Sí (desde golang) |
| API Node.js + Express | node:20-alpine | ~80 MB | ~210 MB | Parcialmente |
| App Python + FastAPI | python:3.12-slim | ~60 MB | ~190 MB | Parcialmente |
| App Python + TensorFlow | python:3.12-slim | ~600 MB | ~730 MB | Sí |
| App Java Spring Boot | openjdk:21-slim | ~100 MB | ~350 MB | Sí |
| API Node.js sin optimizar | node:20 | ~150 MB | ~1.250 MB | No todavía |
Casos típicos con números reales
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 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 que inflan el tamaño
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-install-recommends en apt: apt-get install -y paquete sin la flag 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/*.
Ejemplo: API Node.js con Alpine
Imagen base: Alpine → 5 MB
Dependencias: Node.js runtime (~45 MB) + node_modules producción (~80 MB) = 125 MB
Total estimado: 5 + 125 = 130 MB
130 MB — imagen liviana, apta para deploy directo sin multi-stage
Preguntas frecuentes
¿Cómo calcula Docker el tamaño total de una imagen?
El tamaño total de una imagen Docker es la suma de todas sus capas descomprimidas. Cada instrucción
RUN, COPY y ADD en el Dockerfile crea una capa inmutable identificada por un hash SHA-256. Cuando corrés docker images, el tamaño que ves es la suma en disco de todas esas capas extraídas. Lo que se transfiere al hacer docker pull es el tamaño comprimido con gzip, que representa típicamente entre el 40% y el 60% del tamaño en disco. Por ejemplo, una imagen que pesa 500 MB en disco generalmente ocupa unos 200–225 MB en el registro.¿Qué imagen base conviene usar y cuánto pesa cada una?
Los pesos aproximados de las imágenes base más comunes son: scratch (0 MB, solo para binarios totalmente estáticos), Alpine Linux (~5–7 MB, usa musl libc y BusyBox), Distroless static (~2 MB), Debian Slim (~80 MB), Ubuntu 24.04 (~77 MB), node:20-alpine (~130 MB), node:20-slim (~240 MB), node:20 (~920 MB), python:3.12-slim (~130 MB), python:3.12 (~920 MB), golang:1.22 (~800 MB). Alpine es la opción más liviana, pero su uso de musl libc en vez de glibc puede generar problemas de compatibilidad con librerías Python con extensiones C o binarios compilados para glibc.
¿Qué es un multi-stage build y cuánto puede reducir el tamaño de mi imagen?
Un multi-stage build usa múltiples instrucciones
FROM en un solo Dockerfile: las primeras etapas compilan o instalan dependencias de desarrollo, y la etapa final solo copia los artefactos necesarios para correr la app. Los ahorros reales son significativos: una app Go pasa de ~800 MB (con toolchain) a ~10–15 MB (binario estático en scratch). Una app Node.js pasa de ~1,2 GB a ~180–250 MB. Una app Java con Spring Boot pasa de ~700 MB a ~250 MB usando JRE slim. En general, un multi-stage bien implementado reduce el tamaño entre un 70% y el 95%.¿Cómo veo el peso de cada capa de mi imagen para saber dónde está el problema?
Tenés tres opciones según el nivel de detalle. La primera es
docker history nombre-imagen, que muestra el tamaño de cada capa y la instrucción que la generó. La segunda es docker inspect nombre-imagen, que devuelve un JSON con todos los metadatos incluyendo los hashes de cada capa. La tercera y más poderosa es Dive, una herramienta open-source que permite navegar capa por capa de forma visual, ver exactamente qué archivos agrega o modifica cada instrucción, y te da un porcentaje de 'eficiencia' de la imagen. Dive es especialmente útil para detectar archivos de caché de apt o pip que quedaron en capas anteriores.¿Por qué mi imagen pesa más de lo esperado aunque usé Alpine?
Hay varios errores comunes que inflan el tamaño incluso partiendo de Alpine. El más frecuente es no limpiar el caché de apk: el comando correcto es
apk add --no-cache paquete o agregar rm -rf /var/cache/apk/* al final del mismo RUN. El segundo error es usar múltiples instrucciones RUN en vez de encadenarlas con &&: cada RUN crea una capa nueva, y los archivos eliminados en una capa posterior no reducen el tamaño de la imagen porque la capa original ya fue sellada. El tercer error es copiar directorios completos con COPY . . sin un .dockerignore bien configurado.¿Las capas se comparten entre imágenes en el mismo host Docker?
Sí, y es una de las ventajas más importantes del sistema de capas de Docker. El driver de almacenamiento por defecto en Linux moderno es overlay2, que almacena cada capa una sola vez identificada por su hash SHA-256. Si tenés 10 microservicios basados en
node:20-alpine, la capa de Alpine (~7 MB) y la de Node (~163 MB) se almacenan una única vez en el host. En un clúster Kubernetes con 20 nodos, el segundo pull de la misma imagen base es prácticamente instantáneo porque las capas ya están en disco.¿Existe un límite de capas en una imagen Docker?
Con el driver overlay2 (el default en Linux moderno con kernel 4.x+), el límite es de 128 capas por imagen. En práctica casi nunca se llega a ese número, pero es un incentivo más para consolidar comandos. Cada instrucción
RUN, COPY y ADD crea una capa nueva: un Dockerfile con 50 instrucciones RUN separadas tiene 50 capas. La buena práctica es encadenar comandos relacionados con && para reducir capas y eliminar el caché de apt en la misma capa donde se instaló.¿Cómo afecta el tamaño de la imagen a los tiempos de deployment en Kubernetes o en un pipeline de CI/CD?
El impacto es directo y se siente en producción. En un nodo de Kubernetes con ancho de banda típico de 1 Gbps a un registro como ECR o GCR, descargar 1 GB toma aproximadamente 30–90 segundos con la latencia real y el overhead de descompresión. Una imagen de 100 MB se descarga en 3–8 segundos. En escenarios de autoscaling ante picos de tráfico, la diferencia entre un pod que arranca en 10 segundos y uno que tarda 90 segundos puede ser crítica. En pipelines de GitHub Actions o GitLab CI, el pull de la imagen base es un paso que se repite en cada job: bajar de 900 MB a 150 MB puede ahorrar 2–3 minutos por build.
¿Cuánto cuesta almacenar imágenes en Docker Hub, ECR o GitHub Container Registry?
Los costos varían por proveedor. Amazon ECR: USD 0,10 por GB/mes para imágenes privadas; los primeros 500 MB/mes son gratis. GitHub Container Registry (ghcr.io): gratis para repositorios públicos; para privados se consume del storage de GitHub Actions (500 MB gratis con el plan Free). Docker Hub: el plan gratuito permite 1 repositorio privado; el plan Pro (USD 5/mes) incluye repositorios privados ilimitados. Google Artifact Registry: USD 0,10/GB/mes con los primeros 0,5 GB gratis. En todos los casos, imágenes más pequeñas reducen directamente la factura de storage y los costos de transferencia.
¿Qué es una imagen distroless y cuándo conviene usarla?
Distroless son imágenes mantenidas por Google (disponibles en gcr.io/distroless) que contienen solo el runtime necesario para correr una aplicación, sin shell, sin gestor de paquetes, sin utilidades del sistema operativo. El resultado es una imagen más pequeña y con una superficie de ataque mínima: sin bash, no hay forma de ejecutar comandos arbitrarios si un atacante compromete el contenedor. Pesos típicos:
distroless/java17 (~220 MB), distroless/python3 (~50 MB), distroless/nodejs20 (~165 MB), distroless/static (~2 MB). La contrapartida es que el debugging se complica porque no tenés shell para entrar al contenedor.¿Cómo limpio el espacio ocupado por imágenes Docker en mi máquina?
Docker acumula imágenes, capas intermedias y caché de build que pueden ocupar decenas de GB. Los comandos clave:
docker image prune elimina solo imágenes 'dangling' (sin tag). docker image prune -a elimina todas las imágenes que no tienen ningún contenedor usando. docker system prune -a es el más agresivo: elimina imágenes sin usar, contenedores detenidos, redes no usadas y todo el caché de build. docker system df muestra cuánto espacio usa cada componente. En servidores de CI/CD es recomendable ejecutar docker system prune -f al final de cada pipeline.¿Qué es BuildKit y cómo ayuda a optimizar el tamaño y el tiempo de build?
BuildKit es el backend de build moderno de Docker, habilitado por defecto desde Docker 23.x. Sus principales ventajas son: caché de capas más inteligente, detectando qué cambió realmente en vez de invalidar todo; builds en paralelo de múltiples etapas en multi-stage builds; y caché de mounts con
--mount=type=cache que permite cachear directorios como /root/.cache/pip o node_modules entre builds sin incluirlos en la imagen final (esto solo reduce tiempo de build, no el tamaño de la imagen).Fuentes y referencias
Metodología y confianza
Editorial
Calculadora de tecnología revisada por el equipo editorial de Hacé Cuentas, contrastada con Docker Documentation – Best practices for writing Dockerfiles, según nuestra política editorial y metodología.
Actualización
Última revisión: 20 de junio de 2026. Los parámetros se verifican periódicamente con las fuentes citadas.
Privacidad
Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos.
Limitaciones
Resultados orientativos. Para decisiones críticas, consultá con un profesional.
📌 Cómo citar esta calculadora
Rodríguez, M. (2026). Calculadora de tamaño de imagen Docker (capas + MB). Hacé Cuentas. https://hacecuentas.com/calculadora-imagen-docker-capas-peso-mb
Contenido bajo licencia CC-BY 4.0 — reutilizable citando la fuente con enlace a Hacé Cuentas.