AITM permite ejecutar scripts propios de mantenimiento y automatización periódicos directamente dentro de la instancia en ejecución: sin reconstruir la imagen de Docker, sin volver a desplegar, solo reiniciando el contenedor.

User Jobs (Scheduled Plugin Jobs)

Dónde se encuentra la carpeta de plugins

Cada compilación de versión de AITM (variantes Docker full, online y thin) incluye una capa plugins-runtime/ integrada en la imagen. Sin embargo, la carpeta que realmente importa es el volumen de datos persistente montado: plugins dentro del directorio de datos — normalmente $AITM_DATA_DIR/plugins dentro del contenedor en ejecución, no una ruta dentro de la imagen.

• Empieza vacía en la primera instalación.
• En el primer arranque, el entrypoint del contenedor la rellena con el plugin de referencia example-scheduled-job, pero solo si ese subdirectorio no existe ya, de modo que las ediciones propias en esa carpeta sobreviven a las actualizaciones y los reinicios.
• AITM vuelve a analizar el directorio de plugins en cada arranque del contenedor, por lo que, tras añadir o editar un job, es necesario reiniciar el contenedor para que se detecte (no hace falta reconstruir).

Cómo añadir un job propio

1. Crear un nuevo subdirectorio bajo la ruta montada plugins/ (un directorio por job/plugin).
2. Añadir en él un archivo plugin.json que contenga un array aitm.jobs.
3. Añadir el archivo de script al que apunta el handler.path del job.
4. Reiniciar el contenedor de AITM.

Estructura de plugin.json

Campo	Descripción
name	Identificador único del job.
label	Nombre legible que se muestra en la interfaz.
intervalMs	Frecuencia con que se repite el job, en milisegundos.
priority	Prioridad de planificación; véase la nota de seguridad más abajo: "high" está reservado para los jobs internos de AITM.
timeoutMs	Tiempo máximo de ejecución antes de que el job se termine.
onTimeout	Qué ocurre cuando se alcanza el tiempo de espera.
heavy	Marca el job como intensivo en recursos.
parallel	Si puede ejecutarse de forma concurrente con otros jobs.
concurrencyGroup	Grupo dentro del cual los jobs nunca se ejecutan de forma concurrente.
after	Jobs que deben terminar antes de que este se ejecute.
next	Job que se ejecuta cuando este termina correctamente.
minFreeRamMb / minFreeCpuPercent	Recursos libres mínimos necesarios para ejecutarse.
kind	'in-process' | 'child-process' | 'remote' — cómo se ejecuta el job.
allowedModes	Modos del servidor en los que se permite ejecutar el job.
handler	{ type: 'script', path, args, env } — qué se ejecuta y cómo.

Ejemplo práctico

Una estructura ilustrativa coherente con el example-scheduled-job incluido:

{
  "aitm": {
    "jobs": [
      {
        "name": "example-scheduled-job",
        "label": "Example Scheduled Job",
        "intervalMs": 3600000,
        "priority": "normal",
        "timeoutMs": 60000,
        "kind": "child-process",
        "handler": {
          "type": "script",
          "path": "./run.js",
          "args": [],
          "env": {}
        }
      }
    ]
  }
}

Ajuste de un job sin volver a desplegar

Un operador puede sobrescribir el intervalo, la prioridad o el estado habilitado de un job en vivo mediante REST, sin reiniciar el contenedor ni volver a desplegar:

• GET /api/scheduler/jobs/:name/override
• PUT /api/scheduler/jobs/:name/override

La referencia técnica completa (detalles internos del esquema del manifiesto de jobs, semántica de kind/allowedModes, mecánica de tiempo de espera/reintentos) se encuentra en la propia documentación de AITM.