RunWisp propose une alternative auto-hébergée à cron avec un historique d'exécution complet

Un nouvel utilitaire auto-hébergé nommé RunWisp s'est imposé comme une solution moderne de planification des tâches sur des serveurs individuels. Sorti fin 2026, cet outil combine les fonctionnalités de cron, des superviseurs de processus et des lanceurs de jobs dans un seul binaire. Il s'adresse aux développeurs et aux administrateurs système qui ont besoin de tâches en arrière-plan fiables et auditables, sans la complexité des moteurs de workflow distribués.

Ce qu'il s'est passé

RunWisp introduit une approche unifiée pour l'exécution de tâches périodiques et de services longue durée sur des machines individuelles. Contrairement au cron standard, qui échoue silencieusement si un script génère une erreur ou se bloque, RunWisp agit comme un superviseur. Il enregistre chaque exécution, suit les codes de sortie et gère le cycle de vie de chaque tâche. Le projet est écrit en Go, ce qui donne un binaire léger consommant environ 35 Mo de RAM à l'état inactif. Il prend en charge les environnements Linux, macOS, Windows Subsystem for Linux (WSL) et Docker, tant sur les architectures x86_64 que arm64.

L'outil se distingue en maintenant une configuration simple et portable. Tous les paramètres résident dans un unique fichier runwisp.toml, que les utilisateurs peuvent versionner parallèlement à leur code applicatif. Le tableau de bord et l'interface utilisateur en terminal (TUI) sont inclus dans le même binaire, ne nécessitant aucune installation séparée de serveur web ou de base de données. Il utilise SQLite pour la gestion de l'état local, garantissant la persistance des données même si le démon plante ou si le serveur perd l'alimentation. Au redémarrage du service, il marque toute tâche interrompue comme ayant planté, plutôt que de la laisser dans un état bloqué.

La migration depuis les configurations existantes est conçue pour être progressive. RunWisp ne modifie pas les crontabs au niveau système ni n'interfère avec d'autres planificateurs. Il inclut une fonctionnalité d'importation qui lit les entrées crontab existantes et génère un fichier de configuration annoté. Cela permet aux opérateurs de déplacer une tâche à la fois, en marquant certaines tâches spécifiques pour une revue manuelle avant de basculer entièrement vers le nouveau système. Le projet met l'accent sur la facilité de désinstallation, assurant que la suppression de l'outil ramène le système à son état précédent sans artefacts résiduels.

Détails clés

• Licence et coût : Le démon est publié sous licence GPL-3.0 et est gratuit à auto-héberger, sans paliers payants ni verrouillage de fonctionnalités.
• Utilisation des ressources : Le binaire fait environ 35 Mo et utilise une mémoire minimale, ce qui le rend adapté aux petites machines virtuelles ou conteneurs.
• Gestion des fuseaux horaires : Les expressions cron sont évaluées dans les fuseaux horaires configurés, avec une logique explicite pour les transitions d'heure d'été afin d'éviter les exécutions sautées ou dupliquées.
• Modèle de sécurité : Le démon ne nécessite pas de privilèges root ; il peut s'exécuter en tant qu'utilisateur standard, abaissant les privilèges par tâche si nécessaire.
• Résilience : L'état survit aux plantages et aux coupures de courant, avec une récupération automatique du planificateur au redémarrage via des wrappers systemd ou launchd.
• Portée : Il est conçu pour des tâches indépendantes sur une machine unique, et non pour des pipelines complexes multi-étapes ou des workflows distribués.

Contexte

Les tâches cron traditionnelles sont omniprésentes mais fragiles. Elles fonctionnent selon un modèle « fire-and-forget » (tirer et oublier), ce qui signifie que si un script échoue, se bloque ou produit une sortie inattendue, l'administrateur système reste souvent dans l'ignorance jusqu'à ce qu'un problème en aval survienne. Les superviseurs de processus comme les timers systemd ou supervisord offrent une meilleure fiabilité mais manquent de la syntaxe intuitive de planification de cron. À l'inverse, les moteurs de workflow modernes comme Airflow ou Dagu fournissent une gestion robuste des dépendances mais introduisent une charge opérationnelle significative pour des tâches simples sur un serveur unique.

RunWisp tente de combler ce fossé en agissant comme une « couche inférieure » aux outils d'orchestration complexes. Il offre la familiarité de la planification de cron avec l'observabilité d'un superviseur. En enregistrant chaque exécution et en gérant les états des processus, il donne aux opérateurs une visibilité sur ce qui s'est passé, quand cela s'est produit et pourquoi cela a pu échouer. Ce modèle est particulièrement pertinent pour les petites et moyennes entreprises qui gèrent leur propre infrastructure et ont besoin de fiabilité sans maintenir un cluster Kubernetes dédié ou une infrastructure de file de messages.

Pourquoi c'est important

Pour les équipes exécutant des logiciels auto-hébergés, les échecs silencieux des tâches en arrière-plan sont une source courante de dette technique. Un script de sauvegarde qui échoue discrètement peut entraîner une perte de données, tandis qu'un processus worker bloqué peut dégrader les performances de l'application. RunWisp répond à ce problème en fournissant une piste d'audit pour chaque exécution. Les opérateurs peuvent voir exactement quand une tâche a été exécutée, combien de temps elle a pris et si elle a réussi. Cette visibilité réduit le temps consacré au débogage de problèmes intermittents et augmente la confiance dans les tâches de maintenance automatisées.

La conception de l'outil simplifie également la gestion de l'infrastructure. En consolidant la planification et la supervision dans un seul binaire, il réduit le nombre de composants mobiles dans un environnement serveur. Il n'est pas nécessaire de configurer des bases de données séparées, des serveurs web ou des systèmes d'authentification pour le tableau de bord de surveillance. Cette simplicité abaisse la barrière à l'entrée pour les petites équipes qui peuvent ne pas disposer de ressources DevOps dédiées. De plus, la capacité de migrer progressivement signifie que les équipes peuvent adopter l'outil sans risquer de perturber les flux de travail critiques existants.

Ce que vous pouvez faire

• Évaluez RunWisp d'abord pour les tâches en arrière-plan non critiques, telles que la rotation des logs ou le nettoyage des fichiers temporaires, pour tester sa fiabilité dans votre environnement.
• Utilisez la commande runwisp import cron pour générer une configuration de départ à partir de votre crontab existant, en vérifiant l'exactitude de chaque tâche générée.
• Épinglez la version spécifique du binaire que vous déployez et maintenez des sauvegardes régulières du fichier runwisp.toml et du répertoire de données.
• Configurez explicitement les paramètres de fuseau horaire pour chaque tâche afin d'éviter toute ambiguïté lors des changements d'heure d'été.
• Intégrez l'outil à votre système d'init existant (systemd ou launchd) en utilisant les wrappers d'installation fournis pour assurer les redémarrages automatiques.
• Consultez le CHANGELOG du projet avant toute mise à niveau pour comprendre les éventuels changements cassants, car le logiciel est encore dans ses premiers stades de développement (cycle de vie 1.x).