RunWisp junta cron, servicios y observabilidad en un solo binario en Go
El proyecto ejecuta tareas programadas y servicios desde un archivo TOML, con interfaz web, TUI y CLI, y SQLite embebido. Licencia GPL-3.0 y sin clúster.
RunWisp es un binario único escrito en Go que lanza trabajos de cron y servicios definidos en un archivo TOML, y añade encima una interfaz web donde ver qué se ejecutó, cuándo, con qué código de salida y qué texto imprimió. Su autor, Richard, lleva casi un año con ello y lo ha presentado en el subreddit de self-hosted. La idea no es nueva, pero el envoltorio sí: al binario le acompañan una TUI para quien vive dentro de una sesión SSH y una CLI para automatizar.
El origen está en el trabajo de oficina. Los scripts vivían en el crontab de un servidor y el responsable de devops acababa siendo el intermediario de todo: alguien pedía relanzar una importación o saber por qué había fallado el proceso de la noche anterior, y él entraba por SSH, lo ejecutaba y pegaba el log en el chat. Con RunWisp la configuración vive en un fichero TOML dentro de git y cualquiera abre la interfaz, pulsa ejecutar y mira la salida.
Qué trae y qué no
La interfaz puede disparar y detener trabajos, pero no editarlos. Eso es deliberado: el TOML sigue siendo la única fuente de verdad y no hay dos sitios donde tocar la configuración. Para el despliegue, SQLite va embebido y la interfaz también, así que no hace falta levantar una base de datos al lado ni un contenedor adicional. Hay imagen en runwisp/runwisp para quien prefiera esa vía, y el binario corre en ARM sin problema: el autor lo tiene meses en una Orange Pi.
Trae resueltas las partes aburridas de operar esto: ejecuciones solapadas, reintentos, trabajos que se perdieron mientras la máquina estaba apagada, recuperación tras una caída y logs que van llenando el disco. Un subcomando de importación se come un crontab existente o un archivo de supervisord, de modo que no hay que reescribir a mano lo que ya funciona. Funciona sin conexión y la comprobación de versiones nuevas se puede desactivar con check_updates = false.
Los límites están claros en la propia presentación. No es un motor de workflows ni tiene clúster. Hay una sola contraseña por instancia y no existen cuentas de usuario, así que el consejo del autor es dejarlo detrás de Tailscale o de una VPN. Corre en Linux, macOS y WSL. Para probarlo sin ensuciar nada, bunx runwisp demo levanta una instancia desechable en /tmp con trabajos de ejemplo. El código está bajo GPL-3.0 y se puede ver en el repositorio, con la documentación en runwisp.com.
Un detalle sobre cómo se construyó: el autor escribe software desde 2011 y dice que diseñó la arquitectura y revisó cada cambio contra ella, pero que agentes de IA escribieron buena parte de la implementación. Lo menciona él mismo sin que nadie se lo pregunte.
¿Dónde encaja esto? En el hueco que hoy cubren supervisord, systemd timers y un montón de scripts pegados con cinta aislante. La pregunta es si un proyecto de un solo desarrollador aguanta el relevo en producción, y eso no se responde en un hilo de presentación. Lo que sí se puede hacer ya es el bunx runwisp demo y comprobar si el TOML aguanta la configuración propia sin pelearse con el formato.
