Entretenir votre serveur DQE One Standalone auto-hébergé

Cet article s'adresse à la personne qui installe et exploite votre propre serveur DQE One Standalone (basé sur Docker, auto-hébergé) — il couvre les mises à jour, les sauvegardes, les logs, le stockage et les quelques réglages à revisiter après l'installation initiale. Si vous êtes un utilisateur de l'application plutôt que la personne qui exploite le serveur, consultez plutôt Maintain your data and processes in DQE One Standalone.

Mettre à jour vers une nouvelle version

Il n'y a pas de script de mise à jour séparé à exécuter. Les migrations de base de données s'appliquent automatiquement à chaque démarrage de l'application, donc la mise à jour consiste simplement à : récupérer la nouvelle image fournie par DQE, puis redémarrer vos conteneurs (docker compose up -d, ou l'équivalent pour votre déploiement). Cela couvre aussi le point d'intégration MCP — il s'exécute dans le même processus applicatif, il n'y a donc rien de séparé à mettre à jour ou redémarrer pour lui.

Certains anciens guides d'installation mentionnent des variables comme RUN_COLLECTSTATIC ou une famille de réglages WAIT_HOSTS. Vérifiez auprès du Support si elles s'appliquent encore à votre déploiement avant de vous y fier — elles ne se sont révélées avoir aucun effet dans la version vérifiée pour cet article.

Sauvegarder et restaurer vos données

Il n'existe pas de fonction de sauvegarde intégrée — traitez ceci comme n'importe quel autre déploiement PostgreSQL. Sauvegardez la base de données avec un pg_dump standard, par exemple :

docker compose exec postgres pg_dump -U <DB_USER> -d <DB_NAME> > backup.sql

Restaurez-la de la même façon, avec psql :

docker compose exec -T postgres psql -U <DB_USER> -d <DB_NAME> < backup.sql

Planifiez ces sauvegardes vous-même régulièrement (ou sauvegardez directement le volume Docker de la base de données) — rien dans l'application ne le fait pour vous.

Logs

Le fichier de log de l'application tourne et se nettoie automatiquement tout seul (rotation quotidienne, 7 jours d'historique conservés) — vous n'avez généralement pas besoin de gérer cela.

Le log d'exécution détaillé d'un run n'est pas non plus conservé comme fichier autonome : une fois un run terminé normalement, son contenu est stocké chiffré en base de données et le fichier de log brut est supprimé. Les utilisateurs le téléchargent depuis l'application elle-même (Export Run Logs, voir Monitor and manage a run in DQE One Standalone).

Si la sortie console de votre conteneur grossit dans le temps, vérifiez les réglages de votre pilote de log Docker — le nôtre la plafonne dans notre configuration de référence, mais la vôtre peut être configurée différemment.

Surveiller le stockage

La variable d'environnement DB_MAX_CAPACITY (en octets) est la seule protection de stockage intégrée : lorsque la taille de votre base de données s'en approche, les nouveaux uploads de fichiers affichent un avertissement et un email est envoyé. Cela n'est vérifié qu'au moment de l'upload, pas en continu, et cette protection ne fait rien si la variable n'est pas du tout définie.

Surveillez vous-même la taille réelle de PostgreSQL et l'utilisation disque de l'hôte avec des outils standards, et augmentez DB_MAX_CAPACITY à mesure que vos données grossissent — ne comptez pas dessus pour vous alerter de façon proactive.

Redémarrer et vérifier que ça tourne

Il n'y a pas de point de contrôle de santé intégré, ni de politique de redémarrage configurée par défaut — si le conteneur s'arrête, il reste arrêté sauf si vous avez défini votre propre politique de redémarrage (par exemple restart: unless-stopped dans votre fichier compose) ou un outil de supervision externe. Un moyen rapide de confirmer que l'application répond est d'appeler son URL et de s'attendre à une redirection vers la page de connexion.

Réglages à revisiter dans le temps

• Votre clé de licence (DQE_CLIENT_LICENCE) est vérifiée à chaque connexion — renouvelez-la avant son expiration plutôt qu'après que les utilisateurs commencent à être bloqués.
• DB_MAX_CAPACITY — augmentez-la à mesure que vos données grossissent (voir ci-dessus).

Ne perdez jamais SECRET_ENCRYPTION_KEY et ne la laissez jamais être régénérée une fois définie : si elle venait à ne plus être définie, une nouvelle clé est générée automatiquement au prochain démarrage du serveur, ce qui empêche définitivement de déchiffrer tout ce qui était déjà stocké (Credentials, secrets de Webhook, logs de run) avec l'ancienne clé. Conservez-en une copie sécurisée en dehors du conteneur.

Limites

• Redis n'est pas qu'un simple cache ici : le redémarrer ou le vider fait perdre les jobs en cours ou en file d'attente, ainsi que l'index de recherche utilisé par les processus Index Records (reconstructible en relançant ce process si cela arrive). Des codes de connexion de courte durée y sont aussi stockés, mais les perdre signifie simplement devoir refaire une étape de connexion.
• Le serveur ne gère pas le HTTPS lui-même — gardez-le derrière votre propre reverse proxy avec un certificat valide, de la même façon qu'il a fallu le configurer au départ.