[{"data":1,"prerenderedAt":217},["ShallowReactive",2],{"seo-verification":3,"blog-cron-systemd-timers-automatisation-vps-ma-fr":6,"promo-bar-likely":216},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-cron-systemd-timers-automatisation-vps-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":161,"ctaBody":162,"ctaButton":163,"ctaUrl":164,"relatedPosts":165},230,"cron-systemd-timers-automatisation-vps",{"fr":10,"en":12,"ar":13,"es":14},"cron-vs-systemd-timers-automate-your-linux-vps","cron-مقابل-systemd-timers-أتمتة-vps-linux","cron-vs-systemd-timers-automatizar-vps-linux","cron vs systemd timers : automatiser son VPS Linux","Comparatif pratique cron et systemd timers : syntaxe, logs, migration et dépannage pour vos tâches récurrentes sur VPS Linux.",12,1,false,"2026-08-06T00:00:00+00:00","2026-09-20T21:13:53+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},2,"Automatisation","automatisation","bg-brand-action\u002F10 text-brand-action",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fcron-systemd-timers-automatisation-vps-poster.svg","Sur un VPS Linux, l'automatisation n'est pas un luxe : sauvegardes nocturnes, renouvellement de certificats TLS, purge des logs, sondes de santé — ces tâches tournent sans vous ou elles ne tournent pas. Cron règne depuis des décennies, mais systemd timers offrent une intégration plus profonde avec le gestionnaire de services. Ce guide compare les deux outils, décrit quand choisir l'un plutôt que l'autre, et vous guide pas à pas pour créer ou migrer un timer systemd.",[34,38,49,52,55,99,102,105,133,151,155,158],{"type":35,"title":36,"body":37},"h2","Pourquoi automatiser les tâches sur un VPS ?","Un VPS est un serveur qui tourne en continu, souvent sans supervision humaine directe. C'est précisément pour cela que l'automatisation des tâches récurrentes est fondamentale : personne ne sera là à 3 h du matin pour lancer la sauvegarde ou renouveler le certificat Let's Encrypt. Une tâche oubliée peut se traduire par une perte de données, un certificat expiré qui met le site hors ligne, ou un disque saturé faute de rotation des logs.\n\nEn pratique, cinq catégories de tâches reviennent sur tout VPS Linux sérieux : la **rotation des logs Nginx** (`logrotate` ou un script dédié) qui empêche `\u002Fvar\u002Flog\u002Fnginx\u002F` d'atteindre plusieurs gigaoctets en quelques semaines ; le **nettoyage des images Docker** orphelines (`docker image prune -af`) pour récupérer de l'espace disque sans intervention manuelle ; la **sauvegarde PostgreSQL** (`pg_dump` vers un stockage distant) qui garantit un RPO acceptable en cas de défaillance ; la **vérification du certificat SSL** avant expiration, pour déclencher un renouvellement certbot plutôt que de découvrir un site en HTTPS cassé ; et enfin les scripts de **scraping léger** ou d'indexation planifiée qui doivent s'exécuter à heure fixe. Les deux grands outils disponibles sur Linux — cron et systemd timers — permettent de planifier ces opérations de façon fiable.",{"type":39,"title":40,"items":41},"ul","Cas d'usage typiques sur un VPS",[42,43,44,45,46,47,48],"**Sauvegardes** — dump MySQL ou PostgreSQL vers un stockage distant (`pg_dump -Fc mydb | gzip > \u002Fbackup\u002Fmydb_$(date +%F).sql.gz`), archivage de fichiers avec `rsync` ou `rclone` vers un bucket S3","**Renouvellement de certificats TLS** — `certbot renew --quiet` ou `acme.sh --cron` planifiés deux fois par jour, avec rechargement automatique de Nginx après succès","**Rotation et purge des logs** — suppression des fichiers de plus de 30 jours (`find \u002Fvar\u002Flog -mtime +30 -delete`), compression hebdomadaire, vidage des logs applicatifs en prod","**Nettoyage Docker** — `docker image prune -af`, suppression des volumes orphelins, rotation des logs de conteneurs pour libérer `\u002Fvar\u002Flib\u002Fdocker`","**Sondes de santé** — vérification qu'un service écoute (`curl -sf http:\u002F\u002Flocalhost:3000\u002Fhealth`), redémarrage automatique si besoin, alerte par webhook","**Synchronisation de données** — `rsync` vers un second nœud, mise à jour de caches, synchronisation de fichiers statiques vers un CDN","**Tâches applicatives planifiées** — envoi d'emails de rappel, calcul de rapports périodiques, indexation de contenu, scripts de scraping léger",{"type":35,"title":50,"body":51},"cron : rappel rapide","Cron est présent sur quasiment tous les systèmes Linux. Pour planifier une tâche, on édite la crontab de l'utilisateur courant avec `crontab -e`. La syntaxe repose sur **cinq champs** séparés par des espaces, suivis de la commande :\n\n```\n# ┌── minute (0-59)\n# │  ┌── heure (0-23)\n# │  │  ┌── jour du mois (1-31)\n# │  │  │  ┌── mois (1-12)\n# │  │  │  │  ┌── jour de la semaine (0-7, 0=dimanche)\n# │  │  │  │  │\n  0  3  *  *  *  \u002Fusr\u002Flocal\u002Fbin\u002Fbackup.sh\n```\n\nLes raccourcis `@daily`, `@weekly`, `@monthly` et `@reboot` simplifient les cas courants. Les fichiers déposés dans `\u002Fetc\u002Fcron.d\u002F` appartiennent au système et peuvent spécifier l'utilisateur d'exécution directement dans la ligne. Pour consulter les exécutions passées, deux chemins : `\u002Fvar\u002Flog\u002Fsyslog` (Debian\u002FUbuntu) filtré avec `grep CRON \u002Fvar\u002Flog\u002Fsyslog`, ou `journalctl -t CRON` sur les systèmes avec journald. Un point de vigilance souvent sous-estimé : le `PATH` par défaut de cron est **minimaliste** — `\u002Fusr\u002Fbin:\u002Fbin` — ce qui force à utiliser des chemins absolus dans les scripts, ou à redéfinir `PATH=` en tête de crontab. La variable `MAILTO` contrôle l'envoi des sorties par mail ; la mettre à vide (`MAILTO=\"\"`) désactive le mail silencieusement. Cron ne conserve aucun historique natif des exécutions passées et ne gère pas les tâches manquées si la machine était éteinte.",{"type":35,"title":53,"body":54},"systemd timers : introduction","Un timer systemd est une paire de deux fichiers unitaires : un fichier `.service` qui décrit quoi exécuter, et un fichier `.timer` qui décrit quand le lancer. Le timer est activé par `systemctl enable --now monservice.timer` et piloté par le gestionnaire de services, exactement comme n'importe quel service systemd.\n\nLa directive `OnCalendar=` accepte une syntaxe riche et lisible :\n- `daily` — tous les jours à minuit\n- `Mon *-*-* 03:00:00` — chaque lundi à 3 h\n- `*-*-* 02:30:00` — tous les jours à 2 h 30\n- `*:0\u002F15` — toutes les 15 minutes\n\nLa directive `AccuracySec=` (défaut : 1 minute) permet à systemd de grouper les timers proches pour économiser des réveil processeur — sur un serveur mutualisé ou basse consommation, réduire cette valeur à `1s` garantit l'exactitude de l'heure de déclenchement. La directive `Persistent=true` dans le bloc `[Timer]` est la fonctionnalité qui change tout par rapport à cron : si la machine était éteinte à l'heure prévue, le timer **rattrape l'exécution manquée** au prochain démarrage. Toutes les sorties passent par journald et sont consultables via `journalctl -u monservice.service`. La commande `systemctl list-timers` affiche la liste de tous les timers actifs, leur prochaine échéance et la date de leur dernière activation.",{"type":56,"title":57,"headers":58,"rows":62},"comparison","cron vs systemd timers : tableau comparatif",[59,60,61],"Critère","cron","systemd timer",[63,67,71,75,79,83,87,91,95],[64,65,66],"Syntaxe de planification","5 champs `* * * * *`","`OnCalendar=` lisible (`daily`, `Mon 03:00`)",[68,69,70],"Logs","Sortie mail ou redirection manuelle, `\u002Fvar\u002Flog\u002Fsyslog`","journald natif, `journalctl -u`",[72,73,74],"Tâches manquées (machine éteinte)","Perdues (sauf `anacron`)","`Persistent=true` rejoue après redémarrage",[76,77,78],"Dépendances inter-services","Aucune","`After=`, `Requires=`, `Wants=`",[80,81,82],"Isolation et ressources","Hérite de l'env shell, PATH minimaliste","Cgroups, `MemoryMax=`, `CPUQuota=`",[84,85,86],"Notification d'échec","Aucune en natif","`OnFailure=notify.service` déclenche une alerte",[88,89,90],"Exécution en tant qu'utilisateur précis","Champ user dans `\u002Fetc\u002Fcron.d\u002F`","`User=` et `Group=` dans le `.service`",[92,93,94],"Débogage","Difficile sans log","`systemctl status`, `journalctl -xe`",[96,97,98],"Disponibilité","Tous systèmes Unix (containers, BSD, Alpine)","Systèmes avec systemd (Debian, Ubuntu, RHEL…)",{"type":35,"title":100,"body":101},"Quand conserver cron ?","Cron reste le bon choix dans plusieurs situations concrètes. Sur des **systèmes anciens ou minimalistes sans systemd** — certains conteneurs Docker légers, images Alpine, systèmes BSD — cron est souvent le seul outil disponible et il n'y a aucune raison d'en sortir. Dans un environnement **multi-utilisateurs** où chaque développeur gère ses propres tâches via `crontab -e` sans droits root, cron est plus simple à déléguer : créer un `.service` systemd exige des droits sur `\u002Fetc\u002Fsystemd\u002Fsystem\u002F`.\n\nPour des **scripts one-liner** très simples — un `certbot renew` hebdomadaire, un `rsync` nocturne sans dépendance — la crontab reste lisible et maintenable sans multiplier les fichiers. Cron est aussi le bon choix pour l'**onboarding d'une équipe non-Linux** : la syntaxe des cinq champs, documentée partout, est plus accessible qu'une unité systemd pour quelqu'un qui découvre l'administration système. Enfin, si vos tâches cron **fonctionnent depuis des années sans problème**, la migration n'apporte pas de valeur immédiate. Le critère décisif est la nécessité de logs structurés, de dépendances inter-services ou de contraintes de ressources — si vous n'en avez pas besoin, cron fait le travail.",{"type":35,"title":103,"body":104},"Quand passer aux systemd timers ?","Les timers systemd s'imposent dès que la tâche dépasse le cadre d'une simple commande isolée. Vous avez besoin de **journald** pour tracer chaque exécution, ses sorties et son code de retour sans plomberie manuelle ? Systemd timers. Votre script de sauvegarde doit s'exécuter seulement après que PostgreSQL soit prêt, en déclarant `After=postgresql.service` dans le bloc `[Unit]` ? Systemd timers. Vous voulez limiter la mémoire d'un job de synchronisation pour qu'il n'étouffe pas les autres processus (`MemoryMax=512M`) ? Systemd timers.\n\nLes **dépendances inter-services** sont l'argument le plus fort : un backup lancé alors que la base n'est pas encore disponible après un redémarrage produit un fichier vide sans erreur visible sous cron. Systemd garantit l'ordre. Le **logging intégré** via journald supprime tout le bruit habituel des redirections manuelles — `journalctl -u backup.service --since yesterday` donne l'historique complet avec codes de retour. La gestion des **erreurs** avec `OnFailure=` permet de déclencher une notification (email, webhook) sans polluer le script lui-même. Et si le serveur redémarre à 2 h 58 alors que la sauvegarde de 3 h aurait dû tourner, `Persistent=true` garantit qu'elle s'exécutera au prochain démarrage — ce que cron ne fait pas sans `anacron`.",{"type":106,"title":107,"steps":108},"steps","Créer un timer systemd from scratch (exemple : sauvegarde quotidienne)",[109,112,115,118,121,124,127,130],{"title":110,"body":111},"Créer le fichier service","Ouvrez `\u002Fetc\u002Fsystemd\u002Fsystem\u002Fbackup.service` et saisissez :\n\n```ini\n[Unit]\nDescription=Sauvegarde quotidienne PostgreSQL\nAfter=postgresql.service\n\n[Service]\nType=oneshot\nUser=postgres\nExecStart=\u002Fusr\u002Flocal\u002Fbin\u002Fbackup.sh\n```\n\nLe type `oneshot` indique que le service se termine après l'exécution du script — c'est le type standard pour les tâches planifiées.",{"title":113,"body":114},"Créer le fichier timer","Créez `\u002Fetc\u002Fsystemd\u002Fsystem\u002Fbackup.timer` avec :\n\n```ini\n[Unit]\nDescription=Déclencheur quotidien pour la sauvegarde\n\n[Timer]\nOnCalendar=*-*-* 03:00:00\nPersistent=true\n\n[Install]\nWantedBy=timers.target\n```\n\n`Persistent=true` garantit que si la machine était éteinte à 3 h, la sauvegarde s'exécutera dès le prochain démarrage.",{"title":116,"body":117},"Recharger systemd et activer le timer","Exécutez `systemctl daemon-reload` pour que systemd prenne en compte les nouveaux fichiers unitaires, puis activez et démarrez le timer en une seule commande :\n\n```bash\nsystemctl enable --now backup.timer\n```",{"title":119,"body":120},"Vérifier avec systemctl status","Vérifiez l'état du timer avec `systemctl status backup.timer` — la sortie doit indiquer `active (waiting)` et afficher la prochaine date de déclenchement. Consultez aussi l'état du service après une première exécution avec `systemctl status backup.service`.",{"title":122,"body":123},"Lister tous les timers actifs","La commande `systemctl list-timers --all` affiche un tableau de tous les timers du système avec trois colonnes clés : `NEXT` (prochaine exécution), `LEFT` (temps restant) et `LAST` (dernière exécution). C'est votre tableau de bord pour vérifier que vos timers se déclenchent comme prévu.",{"title":125,"body":126},"Consulter les logs","Accédez à toutes les sorties du service avec `journalctl -u backup.service` pour l'historique complet, ou `journalctl -u backup.service -n 50 --since today` pour les 50 dernières lignes du jour. Le code de retour du script est visible dans la sortie journald.",{"title":128,"body":129},"Ajouter une notification d'erreur (optionnel)","Pour être alerté en cas d'échec, ajoutez dans le bloc `[Unit]` du fichier `.service` :\n\n```ini\nOnFailure=notify-failure@%n.service\n```\n\nCe service peut envoyer un email, un webhook Slack ou un ping ntfy selon votre infrastructure. C'est ce que cron ne peut pas faire nativement sans plomberie dans le script lui-même.",{"title":131,"body":132},"Tester manuellement le service","Avant d'attendre le déclenchement planifié, testez l'exécution immédiate avec `systemctl start backup.service` (sans `.timer`). Consultez le résultat immédiatement avec `journalctl -u backup.service -n 20`. Si le script réussit, la mise en place est validée.",{"type":106,"title":134,"steps":135},"Migrer une tâche cron existante vers systemd",[136,139,142,145,148],{"title":137,"body":138},"Identifier la tâche cron à migrer","Listez vos crontabs avec `crontab -l` (utilisateur courant) et `cat \u002Fetc\u002Fcron.d\u002F*` (système). Notez la commande exacte, l'utilisateur d'exécution et le planning en cinq champs. Par exemple : `30 2 * * 1 root \u002Fusr\u002Fbin\u002Fcertbot renew --quiet` signifie chaque lundi à 2 h 30 en tant que root.",{"title":140,"body":141},"Traduire le planning en OnCalendar","Le format `OnCalendar=` de systemd s'écrit `DayOfWeek Year-Month-Day Hour:Minute:Second`. `30 2 * * 1` devient `Mon *-*-* 02:30:00`.\n\nPour valider la traduction avant de l'appliquer, utilisez `systemd-analyze calendar` :\n\n```bash\nsystemd-analyze calendar 'Mon *-*-* 02:30:00'\n```\n\nLa commande affiche les 10 prochaines occurrences calculées, ce qui élimine toute ambiguïté sur le comportement réel.",{"title":143,"body":144},"Créer les fichiers .service et .timer","Créez `\u002Fetc\u002Fsystemd\u002Fsystem\u002Fcertbot-renew.service` avec `Type=oneshot`, `ExecStart=\u002Fusr\u002Fbin\u002Fcertbot renew --quiet`, et `User=root`. Créez ensuite `\u002Fetc\u002Fsystemd\u002Fsystem\u002Fcertbot-renew.timer` avec `OnCalendar=Mon *-*-* 02:30:00` et `Persistent=true`. Exécutez `systemctl daemon-reload && systemctl enable --now certbot-renew.timer`.",{"title":146,"body":147},"Tester le service avant de désactiver cron","Testez immédiatement l'exécution avec `systemctl start certbot-renew.service` et consultez le résultat via `journalctl -u certbot-renew.service -n 20`. Vérifiez que le timer apparaît dans `systemctl list-timers` avec une prochaine date cohérente. **Ne désactivez la ligne cron qu'après validation.**",{"title":149,"body":150},"Désactiver la ligne cron","Une fois le timer validé, commentez ou supprimez la ligne dans la crontab d'origine. Pour un fichier dans `\u002Fetc\u002Fcron.d\u002F`, renommez-le avec l'extension `.disabled` ou supprimez-le. Laissez cohabiter les deux pendant quelques jours si la tâche est critique — cron et systemd timers n'interfèrent pas.",{"type":152,"title":153,"body":154},"tip","Valider et déboguer vos expressions OnCalendar","Avant d'activer un timer en production, validez toujours votre expression `OnCalendar=` avec `systemd-analyze calendar` :\n\n```bash\nsystemd-analyze calendar \"daily\"\nsystemd-analyze calendar \"Mon *-*-* 02:30:00\"\nsystemd-analyze calendar \"*:0\u002F15\"\n```\n\nChaque commande affiche la prochaine occurrence et les dix suivantes — ce qui rend immédiatement visible une expression mal formée ou un décalage d'heure inattendu. Pour un aperçu de tous vos timers actifs avec leur date de prochain déclenchement et leur temps restant, `systemctl list-timers --all` est votre tableau de bord opérationnel quotidien.",{"type":35,"title":156,"body":157},"Dépannage courant des timers systemd","Cinq problèmes reviennent régulièrement lors de la mise en place des timers.\n\n**1. \"Unit not found\" au `systemctl enable`** — le fichier `.timer` ou `.service` n'est pas dans `\u002Fetc\u002Fsystemd\u002Fsystem\u002F` ou porte un nom incorrect. Vérifiez l'orthographe exacte avec `ls \u002Fetc\u002Fsystemd\u002Fsystem\u002F*.timer`. Un `daemon-reload` est obligatoire avant tout `enable` ou `start` sur un nouveau fichier.\n\n**2. Timer actif mais qui ne se déclenche jamais** — `systemctl list-timers` affiche la colonne `NEXT` avec une date cohérente ? Si `NEXT` est vide ou dans le passé, c'est souvent `Persistent=true` oublié combiné à une machine qui n'a pas redémarré depuis la création du timer. Vérifiez aussi `systemctl status backup.timer` : `active (waiting)` est l'état normal.\n\n**3. ExecStart introuvable ou permission refusée** — le `PATH` dans un `.service` est minimaliste comme dans cron. Utilisez toujours le **chemin absolu** dans `ExecStart=` (`\u002Fusr\u002Fbin\u002Fcertbot` et non `certbot`). Vérifiez que le script est exécutable (`chmod +x \u002Fusr\u002Flocal\u002Fbin\u002Fbackup.sh`) et que l'utilisateur déclaré dans `User=` y a accès.\n\n**4. Permissions sur le script** — si `User=postgres` mais que le script appartient à root sans bit d'exécution pour postgres, le service échouera avec un code 203\u002FEXEC. Consultez `journalctl -u backup.service -n 20` pour voir le message exact.\n\n**5. Conflit entre cron et systemd sur la même tâche** — si vous migrez progressivement, assurez-vous de ne pas avoir les deux actifs en même temps pour une tâche destructrice (purge de logs, rotation de fichiers). Les deux s'exécuteront indépendamment et doubleront les opérations. La vérification est simple : `crontab -l | grep backup` et `systemctl is-active backup.timer`.",{"type":35,"title":159,"body":160},"Conclusion","Cron et systemd timers coexistent sans problème sur le même serveur — vous n'avez pas à tout migrer d'un coup. Conservez cron pour vos tâches simples et vos scripts utilisateur existants, et adoptez les timers systemd pour les nouvelles automatisations qui bénéficient des logs journald, des dépendances inter-services ou de l'isolation par cgroups. La commande `systemd-analyze calendar` et `systemctl list-timers` sont vos alliés pour valider et surveiller vos planifications.","Un VPS Linux prêt pour vos automatisations","Nos VPS cloud sous Ubuntu et Debian incluent systemd, journald et toute la pile moderne. Déployez vos timers, scripts et sauvegardes sur une infrastructure fiable, avec accès root complet et support réactif.","Lancer un VPS Linux","\u002Fvps-cloud",[166,183,198],{"id":167,"slug":168,"slugs":169,"title":173,"excerpt":174,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":175,"updatedAt":176,"category":177,"categories":178,"featuredImage":29,"bgImage":30,"posterImage":180,"relatedSolution":181},31,"installer-apache-airflow-vps",{"fr":168,"en":170,"ar":171,"es":172},"installing-apache-airflow-on-a-vps-self-hosted-automation","تثبيت-apache-airflow-على-خادم-vps-أتمتة-ذاتية-الاستضافة","instalar-apache-airflow-en-un-vps","Installer Apache Airflow sur VPS : Docker Compose et PostgreSQL","Déployez Apache Airflow sur VPS avec Docker Compose : PostgreSQL comme backend, CeleryExecutor pour le scale-out et gestion des secrets chiffrés.","2026-05-20T00:00:00+00:00","2026-11-04T16:30:25+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[179],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Finstaller-apache-airflow-vps-poster.svg",{"categorySlug":25,"appSlug":182},"airflow",{"id":184,"slug":185,"slugs":186,"title":190,"excerpt":191,"readTime":17,"views":23,"isPinned":19,"noindex":19,"publishedAt":192,"updatedAt":193,"category":194,"categories":195,"featuredImage":29,"bgImage":30,"posterImage":197,"relatedSolution":29},212,"woodpecker-ci-pipeline-vps-forgejo",{"fr":185,"en":187,"ar":188,"es":189},"woodpecker-ci-and-forgejo-cicd-pipeline-on-a-vps","woodpecker-ci-وforgejo-خط-أنابيب-cicd-على-خادم-vps","woodpecker-ci-forgejo-pipeline-cicd-vps","Woodpecker CI et Forgejo : pipeline CI\u002FCD sur VPS","Déployez Woodpecker CI v3 avec Forgejo sur votre VPS : installation Docker Compose, pipeline YAML, secrets, runners multi-arch et dépannage OAuth.","2026-08-02T00:00:00+00:00","2026-11-08T01:13:13+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[196],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fwoodpecker-ci-pipeline-vps-forgejo-poster.svg",{"id":199,"slug":200,"slugs":201,"title":205,"excerpt":206,"readTime":207,"views":208,"isPinned":19,"noindex":19,"publishedAt":209,"updatedAt":176,"category":210,"categories":211,"featuredImage":29,"bgImage":30,"posterImage":213,"relatedSolution":214},29,"installer-kestra-vps",{"fr":200,"en":202,"ar":203,"es":204},"installing-kestra-on-a-vps-self-hosted-automation","تثبيت-kestra-على-خادم-vps-أتمتة-ذاتية-الاستضافة","instalar-kestra-en-un-vps","Installer Kestra sur un VPS : automatisation self-hosted","Installez Kestra sur votre VPS : orchestration de workflows déclaratifs en YAML pour vos pipelines data et ETL, en self-hosted avec Docker.",3,8,"2026-05-22T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[212],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Finstaller-kestra-vps-poster.svg",{"categorySlug":25,"appSlug":215},"kestra",true,1794270688793]