Comment auto-héberger DocuSeal en 2026 : liens de signature, SMTP et données d’audit
Auto-hébergez DocuSeal avec les bons ports, un stockage persistant, HTTPS, des secrets, des sauvegardes et des vérifications de mise à niveau. Découvrez comment corriger les liens d’e-mail qui pointent vers localhost.
La plupart des guides d’installation de DocuSeal s’arrêtent au premier chargement de page. C’est trop tôt : les liens d’e-mail pointent vers localhost ou les en-têtes du proxy empêchent le fonctionnement des secure cookies. Un test de production utile est plus exigeant : téléverser un modèle, placer les champs, envoyer une demande de signature, la terminer, puis télécharger le document signé et les informations d’audit.
Le rôle de DocuSeal est simple : signer des documents avec une piste de signature auditable. Son périmètre opérationnel ne se limite pas au processus web : les dépendances, l’état stocké et la route publique doivent donc tous être explicitement définis avant l’arrivée de données réelles.
La configuration de production de DocuSeal
Définissez trois périmètres autour de DocuSeal : l’ingress vers le port 3000, l’état durable et les exigences connexes. Le conteneur peut être remplacé, mais les deux autres éléments doivent avoir des responsables clairement définis. Le contrat réseau de DocuSeal comprend SMTP ainsi qu’une base de données et un stockage de fichiers durables. Conservez les endpoints privés sur un DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à DocuSeal un identifiant de service aux permissions limitées.
Le schéma est complet lorsqu’un client vierge peut téléverser un modèle, placer les champs, envoyer une demande de signature, la terminer, puis télécharger le document signé et les informations d’audit. Collectez les données de durée et de ressources pour le stockage des documents, le traitement des PDF, la distribution des e-mails, les signataires simultanés et les transactions de base de données. Si la transaction échoue, le premier périmètre qui ne se comporte pas comme prévu indique s’il faut examiner le routage, la capacité locale ou un service associé.
Concevez la restauration de DocuSeal avant le lancement
Protégez l’état de DocuSeal avant d’optimiser son conteneur. L’ensemble requis comprend la base de données, les fichiers signés, les modèles et les événements d’audit. Montez /data avant le bootstrap, écrivez des données d’exemple inoffensives, puis remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Si plusieurs stockages doivent rester cohérents, documentez l’ordre dans lequel les écritures sont suspendues et les sauvegardes effectuées.
Conservez des copies en dehors du serveur de déploiement et chiffrez les éléments contenant des identifiants ou du contenu privé. La récupération est réussie lorsque les modèles, les soumissions, les fichiers signés et les événements d’audit sont restaurés et qu’une soumission terminée reste vérifiable. La distinction entre un montage persistant et une copie indépendante est expliquée dans stockage persistant et snapshots.
Fermez les accès temporaires de configuration
Modélisez les menaces liées à l’action effectuée par DocuSeal, et pas seulement à son formulaire de connexion. Dans ce cas, l’erreur la plus risquée consiste à modifier SECRET_KEY_BASE ou à considérer une copie de fichiers comme une sauvegarde d’audit complète. Mettez en place ce périmètre : limitez l’administration des modèles, protégez les données des signataires et définissez l’hôte HTTPS externe avant d’envoyer des liens.
Générez SECRET_KEY_BASE une seule fois, ne le stockez pas dans Git et conservez-le avec le recovery manifest, car sa modification peut invalider l’état chiffré ou signé de l’application. Ne corrigez pas une erreur de permissions en exécutant le conteneur en tant que root ou en montant largement le système hôte. Les limites de ressources font également partie de la conception de sécurité lorsque les utilisateurs peuvent déclencher le stockage de documents, le traitement des PDF, la distribution des e-mails, des signatures simultanées et des transactions de base de données.
Documentez un déploiement DocuSeal fiable
Transformez le smoke test de DocuSeal en commande de release reproductible ou en runbook court. Sa sortie doit démontrer le résultat suivant : téléverser un modèle, placer les champs, envoyer une demande de signature, la terminer, puis télécharger le document signé et les informations d’audit. Notez la version de l’application, le digest du conteneur, le hostname de la route et l’identifiant des données de test avec le résultat.
Exécutez la même vérification après un remplacement ordinaire du conteneur et après avoir restauré la base de données, les fichiers signés, les modèles et les événements d’audit ailleurs. La restauration a réussi lorsque les modèles, les soumissions, les fichiers signés et les événements d’audit sont revenus et qu’une soumission terminée reste vérifiable. Comparez la durée et la consommation liées au stockage des documents, au traitement des PDF, à la distribution des e-mails, aux signataires simultanés et aux transactions de base de données ; une variation importante mérite une investigation, même si l’action finale réussit toujours.
Testez ensuite un échec sans danger : refusez temporairement à l’identité de test l’accès à SMTP ainsi qu’à la base de données et au stockage de fichiers durables. Vérifiez que DocuSeal signale l’erreur et revient à la normale sans modifications manuelles destructrices. Ne conservez que l’extrait de log nécessaire, après l’avoir expurgé. Cette validation en quatre parties couvre le démarrage, la persistance, la récupération et la gestion des erreurs.
Une base Docker pour DocuSeal
Démarrez DocuSeal de manière à garder la route privée jusqu’à la fin du bootstrap.
docker run -d \
--name docuseal \
--restart unless-stopped \
-p 127.0.0.1:3000:3000 \
-v docuseal-data:/data \
-e SECRET_KEY_BASE=replace-with-a-long-random-value \
docuseal/docuseal:latest
Si le processus redémarre en boucle, comparez l’utilisateur attendu par l’image avec le propriétaire de chaque chemin monté. S’il reste actif, testez localement le port 3000, puis passez directement au workflow : téléverser un modèle, placer les champs, envoyer une demande de signature, la terminer, puis télécharger le document signé et les informations d’audit. Épinglez la version de l’image uniquement après la réussite de cette vérification de bout en bout, et consignez la configuration exacte à côté du service.
Évitez qu’un proxy fonctionnel masque une défaillance de l’application
Considérez l’URL DocuSeal externe comme une configuration qui doit survivre aux redéploiements. Définissez d’abord l’hôte de l’application et les paramètres HTTPS avant d’envoyer des liens de signature ; acheminez ensuite le hostname vers le port 3000 en conservant l’hôte et le schéma d’origine.
La checklist d’accessibilité du déploiement peut prouver que les requêtes entrent bien dans le conteneur. À partir de là, le problème connu — les liens d’e-mail pointent vers localhost ou les en-têtes du proxy empêchent le fonctionnement des secure cookies — doit être recherché dans DocuSeal, son état ou sa charge de travail, et non dans l’automatisation des certificats.
Répétez la modification risquée de DocuSeal
Un conteneur opérationnel est nécessaire, mais pas suffisant. L’indicateur de niveau de service est la réussite de « téléverser un modèle, placer les champs, envoyer une demande de signature, la terminer, puis télécharger le document signé et les informations d’audit », tandis que les signaux de pression probables sont le stockage des documents, le traitement des PDF, la distribution des e-mails, les signataires simultanés et les transactions de base de données.
La gestion des changements est importante, car les migrations de base de données et la continuité de SECRET_KEY_BASE doivent être testées : les seuls fichiers signés ne permettent pas de reconstituer la piste d’audit. Conservez l’ancienne image, testez les migrations sur une copie de l’état et documentez la prise en charge ou non du rollback une fois le schéma modifié. Si les liens d’e-mail pointent vers localhost ou si les en-têtes du proxy empêchent le fonctionnement des secure cookies, diagnostiquez le premier périmètre qui diffère de l’environnement fonctionnel.
Intégrez DocuSeal au cycle de vie de Dockup
La couche plateforme de DocuSeal comprend le port 3000, l’ingress, TLS, la configuration d’exécution, le stockage et l’accessibilité des dépendances. Dockup peut reproduire ces éléments pour sa propre infrastructure ou pour un serveur connecté par le client.
L’opérateur termine ensuite la couche produit : définissez l’hôte de l’application et les paramètres HTTPS avant d’envoyer des liens de signature ; appliquez cette règle d’accès — limitez l’administration des modèles, protégez les données des signataires et définissez l’hôte HTTPS externe avant d’envoyer des liens — ; puis exécutez « téléverser un modèle, placer les champs, envoyer une demande de signature, la terminer, puis télécharger le document signé et les informations d’audit ». Enregistrer ce test avec le déploiement évite de confondre le provisioning automatisé avec la disponibilité de l’application.
Foire aux questions
De quoi DocuSeal a-t-il besoin pour un déploiement de production ?
Acheminez le conteneur DocuSeal sur le port 3000 via une seule origine HTTPS. L’exigence réseau associée est SMTP ainsi qu’une base de données et un stockage de fichiers durables. Ne considérez pas DocuSeal comme prêt tant que vous ne pouvez pas téléverser un modèle, placer les champs, envoyer une demande de signature, la terminer, puis télécharger le document signé et les informations d’audit.
Quelles données DocuSeal doivent être sauvegardées ?
Rendez /data persistant et incluez la base de données, les fichiers signés, les modèles et les événements d’audit dans le même recovery manifest. Une restauration propre de DocuSeal n’est validée que lorsque les modèles, les soumissions, les fichiers signés et les événements d’audit sont revenus et qu’une soumission terminée reste vérifiable.
DocuSeal nécessite-t-il HTTPS derrière un reverse proxy ?
Utilisez HTTPS pour l’origine publique de DocuSeal et conservez le port 3000 sur la route interne. Appliquez correctement le paramètre DocuSeal : définissez l’hôte de l’application et les paramètres HTTPS avant d’envoyer des liens de signature. Pour DocuSeal, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transfert et garantit un comportement cohérent du client, sensible à l’origine.
Comment tester une mise à niveau de DocuSeal ?
Restaurez l’état actuel de DocuSeal dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de base de données et la continuité de SECRET_KEY_BASE doivent être testées : les seuls fichiers signés ne permettent pas de reconstituer la piste d’audit. Conservez l’ancienne image DocuSeal jusqu’à ce que les limites de migration des données et de rollback soient clairement comprises.