Pourquoi self-héberger Temporal sur un VPS
Temporal Cloud existe, mais le self-hosting reste pertinent pour plusieurs raisons. D'abord, le coût : à partir de 99 DH/mois, un VPS ServOrbit suffit pour des charges modérées, sans frais à l'action ou au nombre de workflows actifs. Ensuite, la souveraineté des données : vos workflows peuvent traiter des informations sensibles (données clients, tokens d'API internes) qui ne doivent pas transiter par un service tiers. Enfin, la flexibilité : vous contrôlez la version déployée, les politiques de rétention, les intégrations réseau internes.
Cas d'usage de Temporal
Temporal brille là où les cron jobs et queues simples montrent leurs limites. Voici les cas d'usage les plus courants en environnement de production.
Architecture de Temporal auto-hébergé
Comprendre les composants internes vous aide à dimensionner votre VPS et à diagnostiquer les problèmes. Temporal est composé de quatre services principaux qui peuvent tourner dans le même processus (temporalio/auto-setup) ou être déployés séparément à grande échelle.
Temporal vs BullMQ vs Celery
Faites défiler le tableau
| Critère | Temporal | BullMQ | Celery |
|---|---|---|---|
| Durabilité de l'état | Historique complet persisté en base — un workflow interrompu reprend exactement où il en était | État en Redis — une perte Redis signifie une perte de jobs (mitigeable avec AOF/RDB) | Résultats optionnels en backend (Redis, DB) — pas d'historique d'exécution natif |
| Replay et déterminisme | Replay automatique depuis l'historique — le code workflow doit être déterministe, Temporal gère le reste | Pas de replay natif — retry simple sur échec, sans rejouer les étapes précédentes | Retry configurable par tâche, pas de replay d'un workflow multi-étapes |
| UI d'observation | UI riche incluse : liste des workflows, détail de chaque étape, recherche, actions manuelles | Bull Board en plugin tiers — fonctionnel mais limité | Flower en outil séparé — métriques basiques, pas d'historique d'étapes |
| Langages supportés | Go, TypeScript/JavaScript, Python, Java, .NET, PHP (SDKs officiels) | Node.js uniquement | Python principalement, portages partiels pour d'autres langages |
| Performance et latence | Latence plus haute par tâche — optimisé pour la durabilité, pas la rapidité | Très faible latence — conçu pour les jobs haute fréquence | Latence variable selon le broker (Redis < RabbitMQ) — bon pour le volume moyen |
| Cas d'usage idéal | Workflows métier longs et critiques, saga pattern, processus multi-étapes sur plusieurs jours | Files de tâches haute fréquence, traitement d'images, notifications en temps réel | Tâches background Python, pipelines data, intégration dans un écosystème Python existant |
Prérequis techniques
Avant de commencer, vérifiez que votre environnement est prêt.
Déployer Temporal avec Docker Compose
Créer le répertoire de travail
Créez un répertoire dédié et placez-vous dedans.
Télécharger le fichier Docker Compose officiel
Temporal fournit un fichier Compose de référence dans son dépôt GitHub. Téléchargez la version PostgreSQL avec Elasticsearch désactivé pour un démarrage simple.
Créer le fichier de variables d'environnement
Créez un fichier
.envpour personnaliser les credentials PostgreSQL. Ne laissez jamais les mots de passe par défaut en production.Restreindre les permissions du fichier .env
Le fichier
.envcontient des credentials — limitez son accès.Démarrer la stack Temporal
Lancez tous les services en arrière-plan. Le premier démarrage prend quelques minutes :
auto-setupinitialise le schéma PostgreSQL automatiquement.Vérifier que tous les services sont sains
Attendez 60 à 90 secondes, puis vérifiez que les conteneurs sont en état
healthyourunning.Vérifier la connexion au Frontend Service
Utilisez
tctl(Temporal CLI) outemporalCLI pour confirmer que le serveur répond sur le port gRPC.Créer un namespace de production
Temporal utilise des namespaces pour isoler les workflows. Créez un namespace dédié à votre application avec une rétention de 30 jours.
Accéder à l'UI Temporal
L'interface web est disponible sur le port 8080. En local :
http://localhost:8080. En production, placez un reverse proxy nginx avec HTTPS devant ce port (voir section sécurité).Configurer le démarrage automatique
Activez le redémarrage automatique de la stack après un reboot du VPS.
Configurer un Worker Go ou TypeScript simple
Un Worker est le processus qui exécute réellement votre code métier. Il se connecte au Frontend Service, poll une task queue et exécute les Workflows et Activities que Temporal lui dispatch. Voici un exemple minimal dans les deux langages les plus courants.
Temporal UI — surveiller et déboguer les workflows
L'UI Temporal (disponible sur le port 8080) est l'outil central pour observer vos workflows en production. Elle vous permet de :
Sauvegardes PostgreSQL et persistence
La durabilité de Temporal repose entièrement sur PostgreSQL. Une instance non sauvegardée signifie une perte totale de l'historique des workflows en cas de défaillance du VPS.
Dépannage — erreurs fréquentes
Voici les quatre erreurs les plus courantes lors de l'installation de Temporal sur un VPS et leur résolution.
Sécurité : ne pas exposer le Frontend Service sans authentification
Le port 7233 (gRPC Frontend) et le port 8080 (UI) ne doivent jamais être exposés directement sur Internet sans protection. Le Frontend Service n'embarque pas d'authentification native dans les versions open-source : quiconque peut s'y connecter peut démarrer, arrêter ou lire tous vos workflows. Mesures recommandées : (1) bloquez le port 7233 dans ufw et n'autorisez que les IPs de vos Workers (ufw allow from 10.0.0.0/8 to any port 7233) ; (2) placez l'UI derrière un reverse proxy nginx avec authentification HTTP basique ou SSO ; (3) utilisez un VPN ou un réseau privé entre votre VPS Temporal et vos VPS Workers. En production, envisagez mTLS (disponible dans Temporal v1.x) pour chiffrer et authentifier la connexion gRPC.
