Comment héberger OpenUI sur un VPS

OpenUI s'adresse aux développeurs front-end et aux designers qui veulent transformer une idée ("un formulaire de connexion avec un bouton bleu et une option mot de passe oublié") en code HTML/Tailwind/React fonctionnel, rendu instantanément dans le navigateur. Plutôt que de dépendre d'un service en ligne avec des limites de génération et des risques de confidentialité, l'héberger sur votre VPS vous donne un endpoint permanent, partageable par lien interne, où chacun peut prototyper sans installation locale. Point clé : OpenUI a besoin d'un LLM pour générer le code — vous le pointez soit sur un modèle externe via clé API (OpenAI, Anthropic, Mistral…), soit sur un Ollama local tournant sur le même VPS, ce qui garde toute la chaîne en interne. Le rendu temps réel des composants accélère énormément les itérations de maquettage : vous décrivez, vous voyez, vous copiez le code dans votre projet.

OpenUI lui-même est léger : l'application (backend Python + front) tient sur un VPS 2 vCPU / 2 à 4 Go de RAM si vous utilisez une clé API externe pour le modèle. En revanche, si vous voulez tout garder local avec Ollama sur la même machine, dimensionnez selon le modèle cible : comptez 8 à 16 Go de RAM supplémentaires pour un modèle 7B quantifié (ex. Qwen2.5-Coder-7B-Q4), et jusqu'à 32 Go pour un 13B. Prévoyez quelques Go de disque pour les images Docker et davantage si vous stockez des modèles Ollama (chaque modèle pèse 4 à 8 Go). Côté logiciel : Ubuntu 22.04, Docker et Docker Compose, une clé API de modèle (ou Ollama installé), git, et un sous-domaine configuré type ui.mondomaine.com pointant sur votre VPS.

Voici une configuration nginx minimale pour exposer OpenUI avec Basic Auth et HTTPS. Créez /etc/nginx/sites-available/openui avec le contenu suivant : définissez un upstream openui_backend pointant sur 127.0.0.1:7878, puis un bloc server écoutant sur 443 avec votre certificat (Let's Encrypt via Certbot ou DNS-01). Dans le bloc location /, ajoutez proxy_pass http://openui_backend, proxy_http_version 1.1, les headers Upgrade et Connection pour le WebSocket (OpenUI utilise des connexions persistantes pour le rendu temps réel), et auth_basic avec un fichier .htpasswd généré par htpasswd -c /etc/nginx/.htpasswd user. Ajoutez un second bloc server sur le port 80 qui redirige en 301 vers HTTPS. Activez le site avec ln -s dans sites-enabled et rechargez nginx. Pensez à bloquer le port 7878 directement : ufw deny 7878 pour qu'aucun accès non authentifié ne soit possible en contournant le proxy.

La confusion est fréquente dans les recherches et les discussions : OpenUI (par Wandb/W&B) et Open WebUI sont deux projets distincts avec des usages très différents. OpenUI génère du code de composants d'interface utilisateur à partir d'une description textuelle — c'est un outil de prototypage et de génération de code front-end. Open WebUI est une interface de chat web pour interagir avec des LLM (Ollama, OpenAI…), proche de ce que propose ChatGPT mais en auto-hébergé. Pour résumer : si vous voulez créer des composants UI par description, c'est OpenUI. Si vous voulez une interface de chat pour vos modèles locaux, c'est Open WebUI. Les deux peuvent cohabiter sur le même VPS et partager le même backend Ollama — ils se complètent sans se concurrencer.

Pour une chaîne entièrement souveraine, faites cohabiter OpenUI et Ollama dans le même docker-compose.yml sur un réseau Docker interne. Définissez deux services : ollama (image ollama/ollama) et openui (image buildée depuis ./backend). Ajoutez un réseau personnalisé ai_net et rattachez les deux services à ce réseau. Dans les variables d'environnement d'OpenUI, pointez le backend sur http://ollama:11434 — le DNS Docker résout le nom du service automatiquement, sans jamais exposer Ollama sur Internet. Côté qualité de génération, un modèle orienté code (Qwen2.5-Coder, CodeLlama) donne de recommandé composants Tailwind/React qu'un modèle généraliste de même taille. Testez plusieurs et gardez celui dont le rendu est le plus fidèle à vos prompts. Pour activer la persistance des sessions et des préférences utilisateur, montez un volume Docker sur le répertoire de données d'OpenUI (/app/.openui) afin de conserver la configuration entre les redémarrages.

OpenUI reconnaît plusieurs variables d'environnement utiles pour un déploiement sécurisé. OPENAI_API_KEY : clé pour les modèles OpenAI-compatibles (OpenAI, Mistral, Groq…). ANTHROPIC_API_KEY : pour les modèles Claude d'Anthropic. OLLAMA_HOST : URL du backend Ollama (ex. http://ollama:11434 en Docker Compose). HOST et PORT : adresse d'écoute interne (laissez 0.0.0.0:7878 derrière le proxy). Ne stockez jamais vos clés API en clair dans le docker-compose.yml : utilisez un fichier .env (ajouté à .gitignore) ou un gestionnaire de secrets. L'authentification native d'OpenUI étant limitée, privilégiez la Basic Auth nginx pour un accès équipe restreint, ou un proxy d'identité (Authelia, Authentik) si vous avez besoin de SSO et de logs d'accès par utilisateur.

Voici les problèmes rencontrés le plus souvent lors du déploiement d'OpenUI sur VPS. Port 7878 inaccessible : vérifiez que le pare-feu laisse passer le port temporairement pour les tests (ufw allow 7878) ou testez depuis le VPS lui-même avec curl http://localhost:7878. Erreur de connexion au modèle : vérifiez que la variable d'environnement de clé est bien injectée (docker compose exec openui env | grep API). Si vous utilisez Ollama local, vérifiez qu'il est démarré et accessible (curl http://localhost:11434/api/tags). Build Docker qui échoue : assurez-vous de builder depuis le dossier backend/ et non depuis la racine du dépôt. Preview vide après génération : OpenUI utilise WebSocket pour le rendu temps réel — vérifiez que votre configuration nginx passe bien les headers Upgrade: websocket et Connection: Upgrade. Mémoire insuffisante avec Ollama : si le conteneur est tué (OOMKilled), réduisez la taille du modèle (passer à un 3B ou 7B quantifié Q4) ou augmentez la RAM de votre VPS.