2026 Open WebUI 0.13.0 : que vérifier avant la mise à niveau ?

Vous voyez la version 0.13.0 dans les notes de publication et vous vous demandez si le remplacement de l’image suffit ?

Verdict — adapté si vous pouvez sauvegarder les données et coordonner le redémarrage ; ne procédez pas par simple changement d’image. Cette version comprend une migration de base de données. Avant la mise à niveau, préparez une sauvegarde exploitable ; si votre déploiement utilise plusieurs instances ou plusieurs workers, mettez-les à jour ensemble conformément aux consignes officielles, puis vérifiez les fonctions réellement utilisées par votre équipe. Les notes annoncent également des changements de comportement à examiner avant le redémarrage.

Cet article s’adresse aux personnes qui maintiennent une instance Open WebUI et doivent préparer sa sauvegarde, sa mise à niveau et sa vérification.
Il aide les responsables d’installations à plusieurs instances ou workers à organiser une mise à jour coordonnée et à contrôler l’alignement des versions.
Les responsables d’équipe qui utilisent des outils, un terminal ou des sous-agents peuvent aussi repérer les changements à tester dans leurs procédures.

Avant la mise à niveau : distinguer une mise à jour d’image d’une migration

La publication officielle indique que 0.13.0 comporte une migration de base de données ; l’équipe recommande une sauvegarde préalable et la mise à jour synchronisée de toutes les instances dans les déploiements concernés. Ce n’est donc pas une opération à réduire à « télécharger une image plus récente, puis vérifier que la page s’ouvre ». Consultez les notes de publication de la version 0.13.0 et le guide officiel de mise à jour avant de choisir vos étapes.

Commencez par établir l’état réel du déploiement, pas celui que vous pensez avoir :

• relevez la version actuellement exécutée et le tag d’image prévu ;
• identifiez le mode d’installation, par exemple Docker Compose ou Python ;
• recensez les instances et les workers, ainsi que leur rôle ;
• notez où sont conservés la base de données, les fichiers persistants et les paramètres ;
• relevez les variables d’environnement et les fonctions utilisées par l’équipe.

La référence officielle des variables d’environnement peut vous aider à vérifier les paramètres effectivement présents. Ne recopiez pas une liste trouvée dans un ancien fichier d’exemple en supposant qu’elle décrit votre instance : comparez-la à la configuration déployée.

Comment préparer la mise à niveau d’Open WebUI 0.13.0 ? Commencez par confronter votre version et votre mode d’installation aux instructions officielles, puis planifiez une fenêtre où vous pourrez arrêter l’opération si la migration ne se déroule pas comme prévu. Dans une installation à plusieurs instances, consignez également quelles machines doivent être mises à jour ensemble ; une procédure correcte pour un serveur isolé ne suffit pas à décrire une architecture distribuée.

Vous pouvez vérifier le fichier Compose rendu avant l’intervention avec la commande documentée par Docker :

docker compose config

Cette vérification porte sur la configuration résolue ; elle ne prouve ni que votre sauvegarde est restaurable ni que la migration réussira. Examinez le résultat pour confirmer l’image visée, les volumes, les paramètres et les services réellement déclarés. La documentation de docker compose config explique ce que cette commande valide et affiche.

Première étape : préparer une sauvegarde vérifiable

La sauvegarde à protéger dépend de votre installation. Repérez le stockage réellement monté et la base utilisée avant de copier quoi que ce soit : la disposition des données n’est pas nécessairement identique entre deux installations, même si elles exécutent le même logiciel. Ajoutez à votre plan les fichiers de configuration et les variables nécessaires pour reconstruire le service, en prenant soin de traiter les secrets de façon sécurisée.

Que faut-il sauvegarder avant la mise à niveau ? Protégez la base de données, les répertoires persistants utilisés par votre instance et la configuration dont elle dépend. Pour éviter un angle mort, documentez chaque élément à partir du fichier de déploiement et vérifiez que la copie obtenue peut être lue. Une archive créée mais jamais contrôlée n’est pas une preuve suffisante de retour arrière.

Avant le changement, consignez l’image actuellement déployée, les paramètres essentiels et l’état des services. Choisissez ensuite une procédure de retour à la version précédente qui ne suppose pas que la base déjà migrée soit directement compatible avec l’ancienne version. Si le guide ou votre organisation ne permet pas de trancher ce point, ne lancez pas l’opération en production avant d’avoir clarifié la restauration de la base à partir de la sauvegarde.

Pendant l’opération : synchroniser les instances plutôt que les mélanger

Pour une instance unique, suivez le chemin correspondant à votre mode d’installation dans le guide officiel de mise à jour. Évitez d’appliquer une commande générique trouvée ailleurs sans vérifier qu’elle correspond à vos volumes, à votre base et à votre fichier de déploiement. En particulier, ne supprimez pas de volume pour résoudre une erreur de démarrage : vous pourriez effacer les données que vous essayez de préserver.

Les instances Open WebUI doivent-elles être mises à jour ensemble ? Oui, si votre déploiement utilise plusieurs instances ou plusieurs workers : les instructions officielles demandent leur mise à jour synchronisée. Évitez de laisser durablement des instances anciennes et nouvelles accéder au même environnement pendant que la migration ou la vérification est en cours. Contrôlez la documentation d’extension avant de définir l’ordre exact des opérations ; le guide officiel de mise à l’échelle décrit les considérations propres aux déploiements répartis.

Pendant l’intervention, consignez l’heure de début, les changements appliqués et les messages importants des journaux. Suivez l’apparition d’éventuelles erreurs de migration et ne multipliez pas les modifications en parallèle : si une première vérification échoue, suspendre la suite aide à isoler la cause et à garder un retour arrière intelligible. En cas d’échec lié à la base, comparez le message observé avec le guide officiel de dépannage des migrations de base, plutôt que de réinitialiser les données.

Ce tableau ne remplace pas le guide de mise à jour : il sert à choisir entre avancer, coordonner, reporter ou interrompre. La décision dépend d’abord de la possibilité de restaurer les données et de la capacité à traiter toutes les instances de façon cohérente.

Après le redémarrage : valider les données et les usages de l’équipe

Une page accessible ne démontre pas que la mise à niveau est terminée. Vérifiez l’état des services et des journaux, puis confirmez explicitement que la migration de base s’est achevée sans erreur. Comparez la version réellement exécutée avec celle que vous aviez prévue ; dans un déploiement réparti, répétez ce contrôle pour chaque instance au lieu de déduire leur état à partir d’un seul point d’accès.

Comment vérifier qu’Open WebUI fonctionne après la migration ? Utilisez un compte de test ou un compte autorisé, puis contrôlez la connexion, les conversations conservées, les bases de connaissances utilisées et les paramètres indispensables. Faites ensuite un essai représentatif des parcours de votre équipe : connexion à un modèle, appel d’outil, fonction de terminal ou opération d’espace de travail, uniquement si ces fonctions sont activées chez vous.

Comparez ces résultats avec les notes prises avant le changement. Si une conversation manque, si une fonction métier échoue ou si un worker n’a pas rejoint le service, consignez précisément le symptôme avant toute réparation. Cette méthode évite de confondre une migration de base incomplète, un problème de configuration et un incident sans rapport avec la version.

Les consignes officielles de 0.13.0 signalent aussi des changements de comportement : l’emplacement de commandes de l’interface, le nombre de tours d’appel d’outils et le comportement par défaut des limites des sous-agents doivent être examinés dans les notes officielles de la version. Les notes ne justifient pas de supposer que chaque équipe sera touchée de la même manière. Faites plutôt un inventaire de vos procédures et testez les parcours activement utilisés.

Qu’est-ce qui change pour les appels d’outils ? La version annonce une évolution de la limite de tours d’appel ; vérifiez la valeur et le comportement documentés pour cette version, puis testez un scénario réel correspondant à vos usages. Ne transposez pas une valeur lue dans un billet à une autre version, et ne transformez pas la nouvelle valeur par défaut en consigne universelle pour toutes les instances.

Une fois stable : séparer les besoins de l’application et ceux du modèle

L’application Open WebUI et le service qui exécute les modèles ne représentent pas le même travail. Pour évaluer le serveur après la mise à niveau, mesurez ce que consomment votre instance, sa base et ses autres services, puis séparez ces observations des besoins du moteur d’inférence. Un écran d’administration plus lent ne suffit pas, à lui seul, à démontrer un manque de mémoire ou de processeur : confrontez les symptômes aux journaux et aux mesures disponibles sur votre propre système.

Décider selon l’état réel du déploiement

• Si la migration est achevée, les données sont présentes et les fonctions requises passent les essais, conservez la configuration et surveillez le fonctionnement avant d’envisager un changement matériel.
• Si les journaux montrent une pression de ressources reproductible, identifiez d’abord le service concerné, puis comparez sa consommation à la capacité réellement disponible.
• Si votre charge mélange Open WebUI, base de données et inférence, séparez les observations par service ; ne déduisez pas le besoin de la seule taille d’un modèle.
• Si le problème concerne les données ou une migration en échec, revenez au plan de restauration et aux indications de dépannage, au lieu d’acheter un serveur pour compenser une erreur de procédure.
• Si vous souhaitez comparer des capacités de stockage et de mémoire pour une charge durable, vérifiez les informations de capacité mémoire et disque et les options actuellement publiées avant de choisir.

Cette démarche est aussi utile pour les équipes qui envisagent une architecture auto-hébergée : vérifiez les responsabilités d’exploitation et de sauvegarde, au lieu de supposer qu’un hébergement matériel remplace les procédures de maintenance de l’application.

Pour administrer la machine, votre méthode d’accès dépend du système effectivement installé ; les informations sur l’accès au serveur permettent de vérifier ce point sans confondre l’accès au système avec le support de la mise à niveau applicative. L’exploitation d’Open WebUI, la sauvegarde de sa base et la capacité d’exécuter un modèle restent des sujets distincts.

Pour une exploitation durable : choisir l’hébergement selon les contraintes

Une instance de test, un usage léger ou une mise à niveau isolée ne justifient pas automatiquement la location d’un serveur physique. Une machine partagée ou un service infonuagique peut mieux convenir si vous privilégiez une mise en service rapide, une capacité ajustable ou l’absence d’administration matérielle. En revanche, dans un environnement partagé, les ressources et les limites dépendent de l’offre retenue ; vous devez aussi vérifier le stockage, les règles de facturation et les possibilités de sauvegarde avant d’y déplacer une base utilisée par une équipe.

Si votre charge Open WebUI est durable, si vous souhaitez maîtriser l’environnement système et si la concurrence avec d’autres locataires vous préoccupe, un serveur physique AMD dédié peut être une option plus cohérente qu’une machine virtuelle partagée. Il ne résout toutefois ni une migration mal préparée ni le besoin de sauvegardes externes. OSFP Cloud ne propose pas de GPU : ne retenez donc cette voie que si votre architecture sépare l’application WebUI d’un éventuel service d’inférence adapté à vos besoins. Avant de comparer les offres, vérifiez les configurations et systèmes actuellement proposés par OSFP Cloud et confrontez-les à vos mesures, plutôt que de déduire une capacité à partir d’une fiche générique.