Référence des services managés

Cette page détaille chaque service managé : versions, ressources par défaut, port et format de connexion. Les champs communs à tous les services sont rappelés en fin de page.

Champs communs au déploiement

PostgreSQL

Base relationnelle, le service le plus complet de la plateforme.

Connexion (affichée sur la page du service) :

DATABASE_URL=postgresql://UTILISATEUR:MOT_DE_PASSE@HOTE_INTERNE:5432/BASE

Haute disponibilité (HA)

PostgreSQL fonctionne en architecture Blue/Green : un cluster actif (blue) et un cluster de secours (green). Le nombre d'instances actives suit le champ Réplicas. Un pooler de connexions (PgBouncer) est placé devant la base pour stabiliser les connexions lors d'un basculement.

💡 Augmenter Réplicas augmente le nombre d'instances du cluster actif. Le basculement vers le cluster de secours est utilisé notamment lors d'une restauration (Blue/Green).

Extensions PostgreSQL

Deux extensions peuvent être activées au déploiement, dans la section Extensions PostgreSQL :

L'extension est créée au démarrage du cluster — vous n'avez pas de CREATE EXTENSION à jouer vous-même.

ℹ️ PostGIS bascule l'image du service sur une variante spécialisée. Prévoyez ce choix dès le déploiement plutôt qu'après coup.

Bases de données additionnelles

Un cluster PostgreSQL peut héberger plusieurs bases, en plus de la base principale créée automatiquement. C'est utile pour regrouper plusieurs applications sur un même cluster tout en gardant leurs données séparées.

Dans la section Bases de données additionnelles, ajoutez autant d'entrées que nécessaire :

💡 Donnez un utilisateur dédié à chaque base pour les isoler réellement : chaque application n'accède alors qu'à la sienne.

Sur un cluster déjà déployé : ouvrez le déploiement, ajoutez les bases dans la modale d'édition, Enregistrer, puis cliquez sur Synchroniser les bases additionnelles pour les créer réellement sur le cluster.

MySQL

Connexion :

DATABASE_URL=mysql://UTILISATEUR:MOT_DE_PASSE@HOTE_INTERNE:3306/BASE

MongoDB

Connexion :

MONGODB_URI=mongodb://UTILISATEUR:MOT_DE_PASSE@HOTE_INTERNE:27017/BASE

Redis

Connexion :

REDIS_URL=redis://UTILISATEUR:MOT_DE_PASSE@HOTE_INTERNE:6379

Redis est déployé avec authentification. Renseignez au déploiement un nom d'utilisateur et un mot de passe :

• utilisateur default → l'utilisateur par défaut de Redis est protégé par votre mot de passe ;
• utilisateur personnalisé → un utilisateur dédié est créé et l'utilisateur default est désactivé.

🔒 L'accès reste par ailleurs limité au réseau interne de votre environnement : Redis n'est jamais exposé sur Internet.

RabbitMQ

Connexion :

RABBITMQ_URL=amqp://UTILISATEUR:MOT_DE_PASSE@HOTE_INTERNE:5672/

Le nom d'utilisateur et le mot de passe se renseignent au déploiement, dans les champs prévus à cet effet.

L'interface de gestion RabbitMQ est disponible sur le port 15672.

Kafka

Kafka fonctionne en mode KRaft : pas de ZooKeeper, chaque nœud est à la fois contrôleur et broker.

Connexion :

KAFKA_BOOTSTRAP_SERVERS=HOTE_INTERNE:9092
KAFKA_SECURITY_PROTOCOL=SASL_PLAINTEXT
KAFKA_SASL_MECHANISM=SCRAM-SHA-512
KAFKA_SASL_USERNAME=UTILISATEUR
KAFKA_SASL_PASSWORD=MOT_DE_PASSE

ℹ️ Le nom d'utilisateur affiché peut différer de celui que vous avez saisi. Kafka utilise le nom de la ressource comme identité SASL : Nubiecloud le normalise (minuscules, tirets) et lui ajoute un suffixe unique. Reprenez toujours l'utilisateur tel qu'il apparaît sur la page du déploiement.

Rétention

Les messages sont conservés 7 jours, dont les 2 derniers jours sur le disque local du broker. Au-delà, ils sont supprimés — Kafka est un journal à durée de vie limitée, pas un stockage durable.

Dimensionnez le stockage en conséquence : un producteur écrivant 1 Go par jour a besoin d'au moins 7 Go, sans compter la réplication.

Console Kafka intégrée

Chaque déploiement Kafka dispose d'une console dans l'interface, sous l'onglet Kafka :

• Topics — lister, créer, consulter la configuration et le nombre de partitions.
• Groupes de consommateurs — voir les groupes actifs, leur état et leur retard de consommation (lag).
• Messages — parcourir le contenu d'un topic pour vérifier ce qui y transite.

La console ouvre une session éphémère qui se connecte au broker avec vos identifiants, injectés à l'exécution. Elle est réservée aux rôles Développeur et Admin du projet.

À la suppression

Supprimer le déploiement détruit le volume de données, et avec lui les messages encore présents dans les topics. Kafka n'a pas de sauvegarde côté plateforme : ce qui n'a pas été consommé est perdu.

La console énonce ce qui va être détruit avant de demander confirmation. Pour un déploiement qu'on ne veut pas voir disparaître par inadvertance, activez la protection contre la suppression : tant qu'elle est active, la suppression est refusée.

Keycloak

Serveur d'identité : authentification, SSO et comptes utilisateurs pour vos applications, via OIDC et SAML.

Keycloak est la seule brique managée qui soit une application : elle a une URL publique et une console d'administration dans le navigateur.

Prérequis : un PostgreSQL managé

Keycloak n'embarque pas sa base. Il enregistre vos royaumes, utilisateurs, clients et clés de signature dans un PostgreSQL managé que vous choisissez au déploiement — et qui reste le vôtre, avec ses sauvegardes, sa console SQL et ses métriques. Nubiecloud y crée automatiquement une base dédiée, qui apparaît ensuite dans votre console SQL.

Il vous faut donc un PostgreSQL managé dans le même environnement avant de déployer Keycloak. S'il n'y en a aucun, créez-le d'abord.

ℹ️ Certains PostgreSQL peuvent apparaître grisés dans la liste, avec un motif : ce sont des bases créées avec une version antérieure du modèle, qui n'autorisent pas les opérations d'administration nécessaires. Créez-en une nouvelle, ou contactez le support.

Champs au déploiement

Keycloak déroge à plusieurs champs communs : ni mot de passe à saisir, ni stockage à dimensionner, ni base applicative.

Le mot de passe administrateur

À la fin du déploiement, la console affiche une seule fois l'adresse de la console d'administration, l'identifiant admin et le mot de passe généré.

⚠️ Notez ce mot de passe avant de fermer la fenêtre. Il n'est pas réaffiché. Si vous le perdez, contactez le support.

Une fois connecté, changez-le depuis Keycloak (Users → admin → Credentials) : le compte créé au déploiement est un compte d'amorçage.

Le premier démarrage prend deux à trois minutes, le temps que Keycloak initialise son schéma. Une page d'erreur pendant ce laps de temps est normale.

Connecter une application

Créez un client dans la console Keycloak, puis configurez votre application avec l'URL de découverte — la plupart des bibliothèques OIDC n'ont besoin que de celle-ci et en déduisent le reste :

https://VOTRE-KEYCLOAK.apps.nubiecloud.io/realms/VOTRE-REALM/.well-known/openid-configuration

⚠️ Si vous ajoutez un domaine personnalisé, les jetons continuent d'être émis sur l'adresse générée. C'est elle qu'il faut configurer dans vos applications : elle est inscrite dans chaque jeton et ne change jamais.

À la suppression

Supprimer le déploiement détruit aussi sa base sur le PostgreSQL hôte : royaumes, utilisateurs, clients et clés de signature sont perdus, et les applications qui s'authentifient via ce Keycloak cessent de fonctionner.

La console nomme la base concernée et son PostgreSQL avant de demander confirmation. Activez la protection contre la suppression pour qu'un geste accidentel soit refusé.

Le PostgreSQL hôte, lui, n'est pas supprimé — vos autres bases sur ce cluster ne sont pas touchées.

Limites actuelles

Instance unique (pas de haute disponibilité), une seule version tenue à jour par la plateforme, et une montée de version interrompt brièvement le service le temps de la migration de schéma.

n8n

Automatisation de workflows : relie vos applications entre elles — API, bases de données, courriels, webhooks — sans écrire de code d'intégration.

Prérequis : un PostgreSQL managé

n8n n'embarque pas sa base. Vos workflows, exécutions et identifiants de connexion vivent dans un PostgreSQL managé — le vôtre, avec ses sauvegardes, sa console SQL et ses métriques. Choisissez-en un au déploiement, ou laissez Nubiecloud en créer un.

L'accès temporaire, et pourquoi il existe

À la différence de Keycloak, n8n n'a aucun compte administrateur à sa création. Il en demande un à la première ouverture de son adresse — et le crée pour la première personne qui la visite.

Nubiecloud pose donc une authentification devant l'application le temps que vous fassiez votre installation. La console affiche une seule fois l'identifiant nubie et un mot de passe généré.

⚠️ Notez ce mot de passe avant de fermer la fenêtre. Il n'est pas réaffiché.

Le parcours est le suivant :

1. Ouvrez l'adresse, authentifiez-vous avec ces identifiants.
2. Créez votre compte propriétaire dans l'assistant n8n.
3. Revenez sur la fiche du déploiement et cliquez sur « J'ai terminé mon installation — retirer l'accès temporaire ».

Tant que vous ne le retirez pas, vous vous authentifiez deux fois à chaque visite. Une fois retiré, l'application est protégée par son propre compte.

Vous pouvez le remettre à tout moment depuis la même fiche : un nouveau mot de passe est alors généré et affiché une fois. L'ancien cesse de fonctionner.

Champs au déploiement

n8n déroge à plusieurs champs communs : ni mot de passe à saisir, ni stockage à dimensionner.

Le premier démarrage prend une à deux minutes, le temps que n8n initialise son schéma.

À la suppression

Supprimer le déploiement détruit aussi sa base : workflows, historiques d'exécution et identifiants stockés sont perdus. La console nomme la base concernée avant de demander confirmation.

Le PostgreSQL hôte, lui, n'est pas supprimé.

Limites actuelles

Instance unique, sans mode « queue » ni workers séparés : les exécutions se font dans le même processus. Une seule version tenue à jour par la plateforme.

Metabase

Décisionnel : tableaux de bord, questions et graphiques sur vos propres bases de données.

ℹ️ Deux bases à ne pas confondre. Le PostgreSQL hôte stocke ce que Metabase fabrique — questions, tableaux de bord, comptes. Les bases que vous analysez se branchent ensuite depuis Metabase, et peuvent être ailleurs.

Prérequis : un PostgreSQL managé

Comme n8n, Metabase range ses propres données dans un PostgreSQL managé de votre environnement. Choisissez-en un au déploiement, ou laissez Nubiecloud en créer un.

L'accès temporaire

Metabase n'a aucun compte tant que son assistant n'a pas été rempli, et le premier visiteur en devient l'administrateur — avec accès à toutes les bases que vous y brancherez ensuite. La même protection que pour n8n s'applique donc : identifiants affichés une fois, à retirer une fois votre compte créé. Voir le parcours détaillé.

Champs au déploiement

Le premier démarrage prend deux à trois minutes : Metabase joue ses migrations et construit son index de recherche. Une page d'erreur pendant ce laps de temps est normale.

Brancher une base à analyser

Depuis Metabase : Paramètres → Bases de données → Ajouter. Pour une base managée du même environnement, utilisez son adresse interne (visible sur la fiche du déploiement) et les identifiants de la base.

À la suppression

Supprimer le déploiement détruit aussi sa base : questions, tableaux de bord et comptes sont perdus. Les bases que vous analysiez ne sont pas touchées — Metabase ne fait que s'y connecter.

Limites actuelles

Instance unique. La version open source : pas de fonctionnalités payantes (bac à sable de données, incorporation avancée, authentification SSO).

Hasura

Une API GraphQL instantanée sur vos bases PostgreSQL : vous branchez une base, Hasura en expose les tables en lecture et en écriture, sans écrire une ligne de serveur.

ℹ️ Deux bases à ne pas confondre. Le PostgreSQL hôte stocke ce que Hasura retient — les bases déclarées, les permissions, les relations. Les bases que vous exposez en GraphQL se branchent ensuite depuis la console, et peuvent être ailleurs.

Prérequis : un PostgreSQL managé

Comme n8n et Metabase, Hasura range ses propres données dans un PostgreSQL managé de votre environnement. Choisissez-en un au déploiement, ou laissez Nubiecloud en créer un.

Le secret d'administration

Contrairement à n8n et Metabase, Hasura n'a pas d'assistant de premier démarrage : son secret d'administration est posé dès le premier boot, et l'API est fermée immédiatement. Il n'y a donc pas d'accès temporaire à retirer.

• Le secret vous est affiché une seule fois, à la création. Conservez-le : il n'est stocké nulle part où vous puissiez le relire.
• Il n'y a pas de nom d'utilisateur — le secret seul ouvre la console.
• C'est aussi lui qui signe les appels d'administration à l'API, via l'en-tête x-hasura-admin-secret.

Champs au déploiement

Le premier démarrage prend une à deux minutes : Hasura crée son schéma de métadonnées. Une réponse 503 pendant ce laps de temps est normale.

Exposer une base en GraphQL

Depuis la console : Data → Connect Database.

⚠️ Le formulaire propose « Environment variable » par défaut. Vos bases managées ne sont pas déclarées en variables d'environnement : choisissez Database URL et saisissez l'adresse de connexion à la main.

L'adresse prend la forme postgres://utilisateur:motdepasse@adresse-interne:5432/base. L'adresse interne et le nom exact de la base se lisent sur la fiche du déploiement PostgreSQL — le nom de la base n'est pas celui de l'application.

Une fois la base connectée, Data → Track All publie les tables dans le schéma GraphQL. Tant qu'une table n'est pas suivie, elle reste invisible de l'API.

ℹ️ À la première visite, une fenêtre d'accueil avec une vidéo se superpose à la console et intercepte les clics. Fermez-la avant de commencer.

Ouvrir l'API à vos applications

Par défaut tout est fermé : sans le secret d'administration, aucune requête ne passe. Pour qu'une application interroge l'API sans détenir ce secret, définissez des rôles et des permissions par table (onglet Permissions d'une table). C'est le mécanisme prévu — ne diffusez jamais le secret d'administration à un client.

À la suppression

Supprimer le déploiement détruit aussi sa base de métadonnées : bases déclarées, permissions et relations sont perdues. Les bases que vous exposiez ne sont pas touchées — Hasura ne fait que s'y connecter.

Limites actuelles

Instance unique. L'édition communautaire : pas de fonctionnalités payantes (mise en cache des requêtes, mode entreprise, connecteurs propriétaires).

DocuSeal

Signature électronique de documents : vous déposez un contrat, désignez les signataires, et DocuSeal collecte leurs signatures et renvoie le document signé.

ℹ️ DocuSeal consomme un bucket NubiS3. Il est créé automatiquement avec l'application et supprimé avec elle. Il compte dans votre quota de stockage objet — au plan Gratuit, qui en donne un seul, DocuSeal est donc la seule application de ce type que vous pouvez déployer, et vous ne pouvez pas en garder un pour un usage direct en même temps.

Prérequis : un PostgreSQL managé

Comme les autres applications managées, DocuSeal range ses données dans un PostgreSQL managé de votre environnement. Choisissez-en un au déploiement, ou laissez Nubiecloud en créer un.

L'accès temporaire

DocuSeal n'a aucun compte tant que son assistant n'a pas été rempli, et le premier visiteur de son adresse en devient le propriétaire — avec accès à tous les documents qui y transiteront ensuite. Ici ce sont des contrats signés : la même protection que pour n8n s'applique, identifiants affichés une fois, à retirer une fois votre compte créé. Voir le parcours détaillé.

Champs au déploiement

Le premier démarrage prend deux à quatre minutes : DocuSeal joue toutes ses migrations. Une page d'erreur pendant ce laps de temps est normale.

Où vont les documents

Dans un bucket NubiS3 dédié, jamais sur le disque du serveur. C'est ce qui permet à l'application de n'avoir aucun volume à elle : elle peut être redémarrée, déplacée ou mise à jour sans rien perdre.

Ce bucket apparaît dans NubiS3 sous le nom de l'application. Vous pouvez y voir ce qu'il contient, mais vous ne pouvez pas le supprimer tant que l'application existe : ce serait retirer le stockage sous une application en service, qui continuerait de paraître saine tout en perdant chaque document déposé.

Envoyer un document à signer

Depuis DocuSeal : New Document → téléversez un PDF → placez les champs de signature → ajoutez les signataires. Chacun reçoit un lien par courriel.

ℹ️ L'envoi de courriels demande une configuration SMTP. Sans elle, DocuSeal fabrique les liens de signature mais ne les envoie pas : vous devez les copier depuis l'interface et les transmettre vous-même. La configuration se fait dans DocuSeal, Settings → Email.

À la suppression

Supprimer le déploiement détruit deux choses :

• sa base de données — modèles, signataires, historique de signature ;
• son bucket — les documents signés et leurs pièces jointes, définitivement.

La console vous l'annonce dans la fenêtre de confirmation. Téléchargez ce que vous voulez garder avant.

Limites actuelles

Instance unique. Édition communautaire, sous licence AGPL. Un traitement en cours au moment d'un redémarrage n'est pas repris.

Open WebUI

Interface de chat sur des modèles de langage : une seule porte d'entrée pour vos équipes, et la possibilité de faire lire vos propres documents au modèle.

⚠️ Nubiecloud ne fournit aucun modèle. Open WebUI est l'interface, pas le moteur : vous y branchez le fournisseur de votre choix, avec votre propre clé API. C'est un choix délibéré — aucune de vos conversations ne part vers un modèle que vous n'avez pas désigné, et aucune inférence ne vous est facturée par Nubiecloud.

ℹ️ Open WebUI consomme un bucket NubiS3, créé avec l'application et supprimé avec elle. Comme DocuSeal, il compte dans votre quota de stockage objet — au plan Gratuit, qui en donne un seul, vous ne pouvez pas déployer les deux en même temps.

Prérequis : un PostgreSQL managé portant l'extension vector

Open WebUI ne range pas que ses conversations dans son PostgreSQL hôte : son index documentaire y va aussi, sous forme de vecteurs. C'est ce qui lui évite d'avoir un disque à lui — et ce qui exige l'extension vector (pgvector) sur la base hôte.

Cette extension ne peut être posée qu'à la création du PostgreSQL. Conséquence pratique : un PostgreSQL managé créé sans elle ne peut pas héberger Open WebUI. La console vous l'indique en grisant le choix, avec la raison, plutôt que de laisser le déploiement échouer plus tard. Si vous laissez Nubiecloud créer le PostgreSQL, il arrive avec l'extension.

Le compte administrateur

Contrairement à n8n, Metabase et DocuSeal, Open WebUI n'a pas d'accès temporaire à retirer : son compte administrateur est posé au premier démarrage, et l'application est donc protégée dès sa première seconde.

• L'identifiant est une adresse de la forme admin@<adresse-de-votre-application>.
• Le mot de passe est affiché une seule fois, à la création. Notez-le : il n'est réaffiché nulle part, et se change ensuite depuis l'application.
• Dès que ce compte existe, l'inscription se ferme : personne ne peut plus créer de compte depuis la page de connexion.

Pour ouvrir des comptes à vos collaborateurs : Admin Panel → Users. Vous pouvez y rouvrir l'inscription — sachez alors que tout visiteur de l'adresse publique pourra créer un compte.

Champs au déploiement

Le premier démarrage prend plusieurs minutes : Open WebUI joue ses migrations, puis télécharge son modèle d'indexation local (all-MiniLM-L6-v2). Une page d'erreur pendant ce laps de temps est normale ; l'application dispose de sept minutes avant d'être considérée en échec.

Brancher votre fournisseur de modèles

Dans Open WebUI : Settings → Connections → OpenAI API, puis renseignez l'URL de base et votre clé. Tout fournisseur exposant une API compatible OpenAI convient.

Ollama est désactivé : la plateforme n'héberge pas de serveur de modèles. Laissé actif, Open WebUI chercherait à chaque démarrage un serveur qui n'existe pas.

Vos documents

Les fichiers que vous téléversez vont dans le bucket NubiS3 de l'application. Leur index vectoriel, lui, vit dans le PostgreSQL hôte : il pèse donc sur le stockage de cette base, pas sur celui du bucket.

L'indexation est faite localement, par le modèle embarqué dans l'application : le contenu de vos documents ne part pas chez un tiers pour être indexé. Il part en revanche vers le fournisseur que vous avez branché au moment où vous posez une question — c'est lui qui répond.

À la suppression

Supprimer le déploiement détruit deux choses :

• sa base de données — conversations, comptes, index documentaire ;
• son bucket — les fichiers téléversés, définitivement.

La console vous l'annonce dans la fenêtre de confirmation. Téléchargez ce que vous voulez garder avant.

Limites actuelles

Instance unique. Aucun modèle fourni par la plateforme. Édition communautaire, sous licence BSD-3-Clause.

Console SQL

Pour les bases PostgreSQL, Nubiecloud intègre une console SQL dans l'interface : exécutez des requêtes directement depuis la console, sans installer de client.

• Disponible pour : PostgreSQL uniquement.
• Comment : ouvrez le déploiement PostgreSQL → onglet SQL → saisissez votre requête → exécutez. Le résultat est renvoyé dans la console.
• Choix de la base : si le cluster héberge des bases additionnelles, un sélecteur Base de données permet de choisir celle sur laquelle la requête s'exécute. La base ciblée est rappelée au-dessus de l'éditeur.
• Sous le capot : chaque requête s'exécute dans une tâche éphémère isolée, avec des identifiants injectés à l'exécution (jamais exposés).
• Accès : réservé aux rôles Développeur et Admin du projet.

⚠️ Vous êtes responsable des requêtes exécutées. Les modifications (INSERT, UPDATE, DELETE, DROP…) sont irréversibles — la console n'a pas de bouton d'annulation.

Voir aussi

• Services managés — vue d'ensemble
• Backups & restauration