Tu app siempre encendida, tus tareas siempre a tiempo
Convertís tu app en un servicio que arranca solo con el servidor y programás scripts periódicos —backups, limpiezas, health checks— desde formularios. Ves el estado, los logs, la próxima ejecución y actuás con un clic.
- Servicios systemd
- Tareas tipo cron
- Logs incluidos
Ver planes · Crear cuenta gratis
Así se ve en el panel
Capturas reales del panel de ArduMaker, no mockups.
systemd y cron, sin los archivos
Lo que mantiene tu app viva y tus tareas en hora.
- Crear servicios: Pegás el contenido del .service, con opción de iniciarlo al crearlo. Hay plantillas para Node.js, Python y Docker.
- Seguro por defecto: Si el servicio falla al arrancar tras crearlo, se elimina solo. Antes de editar uno existente se hace un backup del archivo.
- Control con un clic: Iniciar, detener, reiniciar y habilitar o deshabilitar el arranque automático.
- Estado claro: Activo, habilitado al arranque, PID, memoria y tiempo encendido.
- Protegidos: ssh, nginx, docker, mysql, postgresql y otros servicios críticos no se pueden eliminar por error.
- Tareas programadas: Nombre, comando y horario; se generan solos el .service y el .timer. Atajos como hourly, daily o weekly.
- Ejecutar ahora y pausar: Probás una tarea sin esperar su horario, la pausás sin borrarla o detenés una ejecución en curso.
- Nunca se saltea: Timers persistentes: si el VPS estaba apagado a la hora programada, la tarea corre al arrancar.
- Logs de todo: La salida de cada servicio y tarea, desde el panel.
Tu app como servicio
- Elegí una plantilla: Node.js, Python o Docker.
- Creá y habilitá: Arranca ahora y con cada reinicio.
- Programá lo periódico: Backups, limpiezas o health checks con su horario.
Cómo funciona por debajo, y qué tener en cuenta
Lo que conviene saber antes de empezar, sin letra chica.
- No se usa cron sino timers de systemd: por cada tarea se generan un .service y un .timer. Es más verboso que una línea de crontab, y a cambio te da estado, logs propios por tarea y la última y la próxima ejecución.
- El horario usa el formato OnCalendar de systemd, con atajos como hourly, daily o weekly. No es la sintaxis de cron: daily en OnCalendar es medianoche, no lo mismo que un @daily de cron.
- Los timers son persistentes: si el VPS estaba apagado a la hora programada, la tarea corre al arrancar. Con cron, esa ejecución simplemente se pierde.
- Si un servicio falla al arrancar justo después de crearlo, se elimina solo y te muestra el error, en vez de dejarte una unidad rota habilitada al arranque.
- Antes de editar un servicio existente se guarda una copia del archivo original.
- Los servicios críticos —ssh, nginx, docker, mysql, postgresql y otros— están protegidos y no se pueden eliminar por error desde el panel.
- Los comandos de las tareas usan rutas absolutas, y los scripts necesitan permiso de ejecución. Es la causa número uno de que una tarea "no haga nada": el PATH del timer no es tu PATH interactivo.
- Los nombres van en minúsculas y sin espacios.
- Necesita systemd corriendo. Verificado en producción sobre Ubuntu 22.04 y compatible con 18.04, 20.04, 24.04 y 26.04; en 16.04 no está disponible.
- Root real por SSH: el panel es un atajo, no una jaula. Todo lo que hace por botón también lo podés hacer a mano.
También se lo podés pedir a Claude, ChatGPT o Cursor
Todo lo que ves en el panel lo puede hacer tu agente de IA a través del servidor MCP de ArduMaker: con tu autorización, con el alcance que le des y con cada acción auditada. Ver qué hace el MCP
Servicios y tareas programadas: preguntas frecuentes
¿Cómo hago que mi app arranque sola al reiniciar el VPS?
Creás su servicio y lo habilitás con un clic.
¿Qué pasa si mi servicio no arranca al crearlo?
Se revierte y se elimina automáticamente, y ves el error.
¿Uso sintaxis de cron?
No, el formato OnCalendar de systemd, que además tiene atajos como daily o weekly.
¿Puedo probar una tarea sin esperar?
Sí, con "ejecutar ahora".
¿Qué pasa si el VPS estaba apagado a la hora programada?
La tarea se ejecuta al volver a arrancar.
¿Por qué timers de systemd y no cron?
Porque cada tarea queda con su estado, sus logs y su próxima ejecución a la vista, y porque los timers son persistentes: si el VPS estaba apagado a la hora programada, la tarea corre al arrancar. Con cron esa ejecución se pierde y no te enterás.
¿Mi tarea corre pero no hace nada, qué reviso primero?
Las rutas. El PATH de un timer no es el de tu shell interactivo: los comandos tienen que ir con ruta absoluta y los scripts necesitan permiso de ejecución. Después, los logs de la tarea desde el panel.
¿Puedo pausar una tarea sin borrarla?
Sí, y también ejecutarla ahora sin esperar su horario, o detener una ejecución que está corriendo.
Servicios que suelen ir juntos
Todo corre en el mismo VPS y se maneja desde el mismo panel.
- Deploy desde GitHub: Vinculás un repo y cada push a la rama elegida actualiza tu app en el VPS, con scripts de build y reinicio.
- Terminal web: Terminales persistentes en el navegador sobre tmux que sobreviven a cortes y desconexiones.
- Backups automáticos: Copia completa semanal en caliente, las últimas 4 guardadas y una copia final al eliminar el VPS.
Menos SSH, más tiempo para tu app Servicios y tareas programadas en el panel de cada VPS. No es un producto aparte: está en el panel de cualquier VPS de ArduMaker, junto al root real por SSH. Ver planes
Cómo funciona por dentro
La documentación técnica de lo que hay en esta página: qué hace cada herramienta, qué cambia, cómo se verifica y qué herramientas MCP la operan.
- Servicios systemd: Crear, editar, controlar y borrar servicios systemd en un VPS, con vuelta atrás si no arrancan y logs del journal.
- Tareas programadas: Comandos con horario en el VPS mediante un servicio y un timer de systemd, con atajos de minutos, ejecución manual y logs.