Pourquoi self-héberger Kestra sur un VPS
Kestra se distingue par son approche déclarative : un workflow (flow) est un fichier YAML versionnable, avec des tâches enchaînées, des conditions, des boucles et des déclencheurs. Cette approche Everything-as-Code séduit les équipes data qui veulent du Git, de la revue de code et de la reproductibilité, sans la lourdeur d'écrire des DAG Python. Self-héberger Kestra sur un VPS prend tout son sens pour les pipelines qui lisent et écrivent dans vos bases de données : les traitements s'exécutent là où vivent vos données, sans transit externe. Kestra peut aussi lancer des tâches dans des conteneurs Docker isolés, ce qui rend un VPS avec un démon Docker accessible particulièrement adapté. L'interface web offre un éditeur de flows, une vue topologique et un suivi d'exécution complet.
Bénéfices concrets du self-hosting
- Workflows en YAML versionnés dans Git, revue de code et reproductibilité totale.
- Plugins riches : bases SQL, S3, scripts Python/Bash, conteneurs Docker, requêtes HTTP.
- Déclencheurs variés : cron, événement, webhook, détection de fichier.
- Exécution au plus près des bases de données internes, sans transit externe.
- Interface web avec éditeur visuel, vue topologique et logs d'exécution détaillés.
- Pas de coût par exécution : seul votre VPS limite le volume de traitements.
Prérequis techniques
Kestra a besoin de PostgreSQL comme backend (pour la version la plus simple, il utilise une base interne, mais PostgreSQL est recommandé en production). Comptez 2 vCPU et 4 Go de RAM au minimum, car la JVM de Kestra consomme de la mémoire ; visez 8 Go si vos flows lancent des tâches Docker ou des scripts data lourds. Prévoyez 30 Go de disque, Docker et Docker Compose, un domaine (orchestrator.votredomaine.ma). Point important : pour que Kestra lance des tâches dans des conteneurs, montez le socket Docker (/var/run/docker.sock) dans le conteneur Kestra.
Déployer Kestra avec Docker Compose
Préparer le VPS
Installez Docker (curl -fsSL https://get.docker.com | sh) et créez /opt/kestra. Vérifiez la RAM disponible : la JVM aime la mémoire, prévoyez au moins 4 Go réellement libres avec free -h.
Écrire le docker-compose
Récupérez le compose officiel de Kestra qui inclut PostgreSQL. Déclarez le service kestra avec l'image kestra/kestra:latest, la commande server standalone, et montez /var/run/docker.sock:/var/run/docker.sock pour activer les tâches conteneurisées.
Configurer le backend PostgreSQL
Dans la section configuration du compose, pointez kestra.datasources vers PostgreSQL avec l'URL JDBC, l'utilisateur et le mot de passe. Définissez aussi kestra.url: https://orchestrator.votredomaine.ma/ pour les liens corrects dans l'UI.
Démarrer Kestra
Lancez docker compose up -d. Au premier démarrage, Kestra crée son schéma dans PostgreSQL. Surveillez docker compose logs -f kestra jusqu'au message indiquant le serveur prêt sur le port 8080.
Reverse proxy et HTTPS
Mettez Caddy devant : orchestrator.votredomaine.ma { reverse_proxy localhost:8080 }. Le HTTPS protège l'accès à l'éditeur de flows et aux logs d'exécution, qui peuvent contenir des données sensibles.
Créer un premier flow YAML
Dans l'UI, créez un flow de test avec une tâche io.kestra.plugin.core.log.Log puis ajoutez un déclencheur cron schedule. Validez qu'une exécution planifiée se lance et apparaît dans la timeline. Versionnez ensuite ce YAML dans Git.
Réglez explicitement la mémoire de la JVM pour éviter les surprises sur un VPS : passez JAVA_OPTS=-Xmx2g (ou la moitié de votre RAM) dans l'environnement du conteneur Kestra. Sans cette limite, la JVM peut tenter de réserver trop de heap et déclencher un OOM kill par le noyau Linux. Pour les pipelines data, utilisez le type de tâche Docker plutôt que Process : chaque traitement tourne dans son propre conteneur avec ses dépendances, ce qui évite de polluer le VPS et garantit la reproductibilité.
