Pourquoi self-héberger Temporal sur un VPS
Temporal résout un problème que peu d'outils traitent vraiment : la durabilité d'exécution. Un workflow Temporal peut durer des secondes ou des mois, attendre un événement humain, réessayer automatiquement une étape échouée, et reprendre exactement là où il s'était arrêté même si le serveur a redémarré entre-temps. Ce n'est pas un outil no-code : on écrit le code du workflow dans un SDK, et Temporal garantit sa réexécution déterministe. Self-héberger sur un VPS est pertinent quand vos workflows pilotent des opérations critiques (paiements, provisioning, orchestration de microservices) et que vous voulez éviter la dépendance et le coût du cloud managé Temporal. Le serveur self-hosted vous donne le même moteur, sous votre contrôle, avec vos propres SLA. Attention : Temporal est plus exigeant que les autres outils de cette série, c'est une infrastructure à part entière.
Bénéfices concrets du self-hosting
- Durabilité native : l'état des workflows survit aux crashs et redémarrages.
- Retries et timeouts automatiques sur chaque activité, sans code de plomberie.
- Workflows écrits dans votre langage : Go, Java, Python ou TypeScript.
- Web UI complète pour inspecter l'historique d'exécution étape par étape.
- Indépendance vis-à-vis du cloud managé : vos données et vos SLA chez vous.
- Idéal pour les sagas, le provisioning et l'orchestration de microservices.
Prérequis techniques
Temporal est composé de plusieurs services (frontend, history, matching, worker) plus une base de données. Pour un environnement de développement ou de petite production, le docker-compose officiel avec PostgreSQL tourne sur 2 vCPU et 4 Go de RAM, mais visez 4 vCPU / 8 Go pour une production sérieuse, car les services Temporal et la base consomment ensemble. Pour de vrais volumes, Temporal recommande Cassandra et un moteur de recherche (Elasticsearch) pour les Visibility queries avancées, ce qui demande davantage de ressources. Prévoyez Docker, Docker Compose, un domaine (temporal.votredomaine.ma) et ouvrez le port 7233 (gRPC) côté réseau interne, le 8080 pour la Web UI.
Déployer Temporal avec Docker Compose
Cloner le dépôt docker-compose
Temporal fournit un dépôt dédié : git clone https://github.com/temporalio/docker-compose.git /opt/temporal && cd /opt/temporal. Il contient plusieurs variantes (PostgreSQL, Cassandra, avec ou sans Elasticsearch).
Choisir la variante PostgreSQL
Pour démarrer raisonnablement, utilisez docker-compose-postgres.yml. Il déploie PostgreSQL, le serveur Temporal multi-services et la Web UI. Adaptez le mot de passe de la base et les ressources allouées.
Lancer le serveur Temporal
Démarrez avec docker compose -f docker-compose-postgres.yml up -d. Le serveur applique automatiquement le schéma (auto-setup). Vérifiez la santé avec docker compose logs -f temporal puis testez le CLI : tctl --address temporal:7233 cluster health.
Sécuriser la Web UI derrière un proxy
La Web UI (port 8080) ne gère pas l'authentification par défaut. Placez-la derrière Caddy avec HTTPS et une protection (basic auth ou SSO) : temporal.votredomaine.ma { basicauth { ... } reverse_proxy localhost:8080 }. N'exposez jamais le port 7233 gRPC publiquement.
Configurer un namespace
Créez un namespace applicatif dédié plutôt que d'utiliser default : tctl --namespace prod namespace register --retention 72h. La rétention détermine combien de temps l'historique des workflows reste consultable.
Connecter un worker de test
Depuis votre application (SDK Python par exemple), connectez un worker à temporal.votredomaine.ma:7233, enregistrez un workflow simple et une activité, et lancez une exécution. Vérifiez son historique pas à pas dans la Web UI.
En self-hosting, surveillez de près la rétention et la taille de la base : chaque événement de chaque workflow est persisté, et un historique trop long ou des millions d'exécutions peuvent faire gonfler PostgreSQL rapidement. Définissez une rétention de namespace raisonnable (par exemple 72h à 7 jours) et activez l'archivage si vous devez conserver l'historique au-delà. Pour la production, séparez les workers applicatifs (votre code) du serveur Temporal sur des conteneurs distincts, voire des VPS distincts, afin qu'un worker saturé ne dégrade jamais le cluster d'orchestration.
