Schedule Jobs (cron)
Correr comandos o scripts en un horario fijo (limpieza de Docker, backups custom, mantenimiento) sin un cron externo. Cada ejecución queda con logs consultables desde el panel.
Tipos de job
| Tipo | Dónde corre | Para qué |
|---|---|---|
| Application | Dentro del contenedor de una app | Comandos puntuales en ese contenedor |
| Compose | Dentro de un servicio de un Compose | Igual, para stacks multi-contenedor |
| Server | Directo en el host remoto | Scripts bash con acceso total |
| Dokploy Server | Dentro del contenedor de Dokploy | Comandos Docker (docker ps, prune) |
Application y Compose Jobs
Corren como docker exec -it <container> <command>. Ejemplo — ver la versión de nginx:
- Crear un Schedule Job → comando
nginx -v→ configurar el cron → guardar y revisar logs.
⚠️ El contenedor destino debe estar corriendo. En Compose, no cambiar
COMPOSE_PROJECT_NAME(Dokploy la usa para identificar el proyecto).
Server Jobs
Scripts bash directo en el host, con acceso a cualquier herramienta instalada.
Dokploy Server Jobs
Corren dentro del contenedor de Dokploy (no en el host), pero con acceso al socket de Docker.
Ejemplo 1 — limpieza automática de Docker
Cron cada 15 min (*/15 * * * *):
#!/bin/bash
docker system prune --force
Automatiza el problema de Gestión de disco: el disco se llena por imágenes/cache de Docker.
Ejemplo 2 — backup de una BD no soportada nativamente (ej. ClickHouse)
#!/bin/bash
backup_file="database_$(date +%Y%m%d_%H%M%S).backup"
container=$(docker ps --filter "name=clickhouse" --format "{{.Names}}")
docker exec -it $container clickhouse-client --query "BACKUP DATABASE mydb TO '/backups/$backup_file'"
# aws s3 cp /backups/$backup_file s3://your-bucket/backups/
Buenas prácticas
- Probar el comando manualmente antes de programarlo.
- Manejar errores dentro del script.
- Considerar el impacto de jobs frecuentes en los recursos.