Saltar al contenido principal

Gestión de disco

Tema operativo, no específico de ningún método de despliegue. Cuanto más se usa Dokploy, más urgente se vuelve.

El hallazgo​

Con solo 3 sitios estáticos triviales desplegados:

$ docker system df
TYPE            TOTAL   ACTIVE   SIZE      RECLAIMABLE
Images          9       7        4.878GB   1.107GB (22%)
Build Cache     63      0        494.9MB   494.9MB (100%)
MétricaValor
Docker5.43 GB — el 65% del uso total del disco
Recuperable ahora~1.6 GB

La lección: el peso no viene de los archivos del proyecto, viene de las imágenes y el cache de Docker. Tres sitios que pesan unos KB generaron 5.43 GB de maquinaria. Extrapolado a 20 proyectos, el disco se llena. La limpieza no es opcional a escala.

Cómo se manifiesta​

Un día un deploy falla con no space left on device. Es confuso porque el error no dice "tienes 40 imágenes viejas acumuladas".

Qué se acumula​

QuéPor qué crece
ImágenesCada deploy genera una. Las viejas no se borran solas.
Build CacheCapas de Nix, node_modules. Con Nixpacks es lo más pesado.
Contenedores ExitedVersiones anteriores. Docker las deja muertas ahí.

Señal clave: Build Cache con ACTIVE 0 = 100% basura, siempre.

Cómo vigilar el disco​

Desde el panel: pestaña Monitoring → gráficas Disk Space y Docker Disk Usage (dona con Build Cache · Containers · Images · Volumes). En Docker → Containers, los marcados Exited son residuo.

Desde terminal:

df -h                # espacio total
docker system df     # desglose de Docker → mirar la columna RECLAIMABLE

💡 No hace falta SSH: Settings → Web Server → Actions → Terminal da shell desde el panel.

Limpieza​

Automática (recomendado): Settings → Web Server → toggle Daily Docker Cleanup. Viene apagado por default. Es un system prune completo — sí limpia el build cache. Con esto basta para el caso normal.

Manual:

docker system prune -af    # imágenes, contenedores parados y build cache

Personalizada: el tooltip apunta a Schedule Jobs para estrategias a medida (ej. docker image prune -af sin tocar volúmenes).

⚠️ Los tres riesgos de la limpieza agresiva​

  1. Borra VOLÚMENES. Guardan datos persistentes (BD, uploads). Docker solo borra los no referenciados, así que un contenedor corriendo está a salvo… pero si está detenido, su volumen queda huérfano y desaparece con datos adentro.

    🔴 Hoy no hay riesgo (solo estáticos stateless). Antes de meter MongoDB o Postgres en Dokploy, esto se reevalúa.

  2. Elimina la ventana de rollback. Configure Rollbacks depende de que existan imágenes previas. Si el cleanup las borra, no hay a dónde volver. Trade-off: disco limpio vs. poder revertir. Para producción se quieren conservar las últimas 2-3 versiones.

  3. Servicios on-demand. Backup runners, cron jobs. Si su imagen no corre cuando pasa el cleanup, se borra y hay que reconstruirla.

Checklist​

  • docker system df ejecutado — línea base registrada
  • Daily Docker Cleanup ACTIVADO (viene apagado)
  • Riesgo de volúmenes anotado para cuando haya bases de datos

Relacionado: El problema de los builds (build server dedicado + registry).