Workflow SDK 5 : chiffré de bout en bout, par région

Ce qui se passe

Workflow SDK permet d'écrire du JavaScript asynchrone ordinaire, avec "use workflow" et "use step", qu'un moteur durable fait survivre aux plantages, aux déploiements et aux longues attentes (un sleep("3d"), par exemple). La version 5 sort après plus de 4 milliards d'étapes et 700 millions d'exécutions, qui ont fait émerger deux usages : l'automatisation (ETL, commandes, abonnements) et les agents, longs et coûteux, donc durables par nature. Vercel annonce des changements sur la sécurité, la fiabilité et la vitesse, sans rupture majeure.

Chiffrement

Le journal d'événements stocke les arguments et les retours de chaque étape pour reprendre après un incident. Cela peut contenir des données de clients, du contexte de modèle, des identifiants. La version 5 chiffre chaque charge utile de bout en bout, avant qu'elle quitte votre code : entrées et sorties des workflows et des étapes, charges des hooks, flux. L'algorithme est AES-256-GCM, avec une clé propre à chaque exécution ; le backend, Vercel compris, ne voit que du chiffré.

• Sur Vercel, aucune configuration ni changement de code : la clé de chaque exécution découle d'une clé liée au déploiement qui l'a créée.
• Les noms, durées et statuts restent visibles ; pour lire une charge, npx workflow inspect run <run-id> --decrypt la déchiffre en local, avec les mêmes permissions que les variables d'environnement du projet, et chaque requête est inscrite au journal d'audit de l'équipe.
• Sur un « World » auto-hébergé, il faut implémenter getEncryptionKeyForRun() et renvoyer les mêmes 32 octets pour une exécution à chaque appel, pour que les relectures déchiffrent.

Les écritures entre exécutions (reprendre le hook d'une autre exécution, démarrer une exécution dans un autre déploiement, écrire dans un flux d'une autre) sont chiffrées pour la clé publique de la cible. Avec experimental_retention: 0, entrées, sorties et contenus de flux sont supprimés dès la fin ou l'échec d'une exécution ; les métadonnées restent. Les attributs d'exécution, nouveaux, sont en clair : n'y mettez aucun secret.

Régions

En version 4, toute exécution vivait en iad1 (Washington), même pour un projet déployé dans plusieurs régions : une étape ailleurs faisait des requêtes inter-régions pour noter sa progression. En version 5, chaque exécution a une région d'origine : état, file et flux y sont servis, par défaut celle de la fonction qui la démarre. Pour la choisir :

// Garder les données de ce client à Francfort
const run = await start(processOrder, [order], { region: "fra1" });

L'option region décide où vivent les données ; les étapes tournent là où l'application est déployée, il faut donc y déployer aussi. Les exécutions de la version 4 restent en iad1. Avec le basculement de fonctions de Vercel, les étapes peuvent tourner dans une région de repli, mais l'état reste dans sa région d'origine.

Vitesse

Le moteur est réécrit : une invocation peut enchaîner plusieurs étapes en ligne, y compris en parallèle, avant de rendre la main, et la relecture est incrémentale. Banc de Vercel (v4.8.12 contre v5.2.0, 8 octobre 2026, production iad1, 1 Ko de JSON par étape) :

Les flux passent par WebSocket sur le World de Vercel, et la compression réduit d'environ 80 % les jetons de modèle diffusés.

Limites

Ce sont des mesures du fournisseur, sur une charge, dans une région : Vercel les présente comme une vue du surcoût du moteur, non comme une prévision pour toute application. Le chiffrement géré par Vercel garde les clés côté plateforme ; l'auto-hébergement exige de gérer les siennes.

Comment s'y prendre

1. Lire la page « what's new » de la version 5, puis pnpm add workflow@latest sur un projet de test.
2. Décider de la région des données sensibles, avec { region }.
3. Poser experimental_retention: 0 si vous n'avez pas à conserver les charges après exécution.

Source : Vercel, en anglais.