Configuration d’instance

La configuration d’instance définit les origines publiques, les secrets et les services proposés aux utilisateurs. Préservez les identifiants existants avant de modifier l’environnement protégé, renseignez tous les paramètres nécessaires à chaque fournisseur optionnel, puis vérifiez l’exposition réseau et les tâches planifiées authentifiées.

Configurer les origines, secrets et capacités de l’instance

Définissez MINDDY_PUBLIC_APP_URL comme une origine absolue unique, sans chemin ni barre finale. Un service public utilise HTTPS ; localhost et une IPv4 privée de confiance peuvent utiliser HTTP. MINDDY_PUBLIC_SUPABASE_URL et MINDDY_PUBLIC_SUPABASE_ANON_KEY doivent désigner la même pile Supabase. Ces valeurs arrivent au navigateur. SUPABASE_SERVICE_ROLE_KEY reste exclusivement côté serveur et est obligatoire en production. Ne la mettez jamais dans une variable publique ni un bundle client. L’URL de base de données sert aux outils et ne remplace pas la configuration API.

Conserver les secrets

L’installateur crée les valeurs manquantes de GIT_STATE_SECRET, GIT_TOKEN_ENCRYPTION_SECRET, AI_KEY_ENCRYPTION_SECRET, FEEDBACK_SSO_ENCRYPTION_SECRET, MINDDY_DATA_ROOT_KEY et CRON_SECRET. La racine de chiffrement contient exactement 64 caractères hexadécimaux. Gardez-la hors de PostgreSQL avec une copie de récupération protégée. Conservez l’environnement en mode 0600 et hors de Git. Ne l’exécutez pas comme script shell et ne l’affichez pas. Relancer l’installation ne renouvelle pas les secrets. Leur perte peut rendre les données existantes illisibles ; une rotation volontaire exige la procédure de récupération correspondante.

Appliquer et contrôler une modification

MINDDY_PUBLIC_SITE_NAME et MINDDY_PUBLIC_CONTACT_EMAIL identifient votre instance. ADMIN_EMAILS est une liste d’administrateurs séparés par des virgules ; l’accès privilégié exige aussi MFA. OAUTH_ISSUER reste normalement vide, sauf si vous publiez volontairement OAuth à une autre origine stable. Désactivez IA et facturation gérées en self-hosted. Activez les services optionnels avec leur configuration complète. Redémarrez ou recréez l’application après un changement de valeurs publiques au runtime ; l’image OCI ne nécessite pas de reconstruction. Le doctor distingue capacité incomplète et panne du cœur. Testez ensuite les liens de compte et callbacks sur l’origine prévue.

Configurer les retours et les signalements de documentation

Définissez MINDDY_FEEDBACK_KEY avec une clé d’intégration de retours pour activer Partager un retour dans l’app. Pour les signalements de documentation, créez une intégration de retours distincte dans le projet destinataire, choisissez l’objectif Documentation par défaut et enregistrez sa clé sous MINDDY_DOCUMENTATION_FEEDBACK_KEY. Les deux clés restent côté serveur. Les envois passent par /api/v1/feedback sur l’origine définie par MINDDY_PUBLIC_APP_URL. Redémarrez l’application après toute modification de ces valeurs.

Signaler une erreur sur un article nécessite un compte connecté. Après connexion, le lecteur retrouve le même article avec le modal Partager un retour ouvert. Le titre et la description sont initialement vides. Après l’envoi, le serveur ajoute l’identifiant de l’article, sa langue, sa révision et son URL publique au signalement ; ces informations ne sont pas des champs modifiables du formulaire. L’intégration de documentation rattache automatiquement le retour à l’objectif choisi. Sans MINDDY_DOCUMENTATION_FEEDBACK_KEY, le bouton de signalement est désactivé avec une explication.

Activer volontairement les fournisseurs optionnels

Le cœur n’exige ni Stripe, ni PostHog, ni compte Cloud, ni clé IA gérée par minddy. Les services externes ajoutent coûts, permissions et destinations des données. Examinez leurs conditions avant activation. Les diagnostics signalent les valeurs manquantes au lieu de choisir un fournisseur de secours. Une instance self-hosted peut employer des clés IA personnelles ou des endpoints locaux accessibles. Laissez MINDDY_MANAGED_AI et MINDDY_MANAGED_BILLING désactivés ; une clé OpenRouter seule ne sélectionne pas Cloud.

Renseigner les fournisseurs

L’email applicatif exige EMAIL_PROVIDER=resend, RESEND_API_KEY, FEEDBACK_EMAIL_FROM et INVITATION_EMAIL_FROM. console est refusé en production ; SMTP Auth reste séparé. Web Push exige les clés VAPID publique et privée et VAPID_SUBJECT ; les abonnements existants dépendent de cette paire. L’analytique exige une paire clé/hôte PostHog complète ; le suivi d’erreurs ajoute MINDDY_PUBLIC_ERROR_TRACKING=1. L’assistant d’installation propose application-email et web-push, à vous de fournir les identifiants externes. N’employez pas les identités d’expéditeur minddy ni ses identifiants de release native sur une autre instance.

Connecter Git et l’exécution de code

GitHub.com et GitLab.com sont pris en charge, contrairement à Enterprise Server et GitLab autogéré. Les connexions lancées par l’utilisateur peuvent utiliser le relais forge géré ; refusez-le avec --no-forge-relay ou MINDDY_FORGE_RELAY=0 puis configurez vos propres applications. Les connexions existantes gardent leur canal jusqu’à reconnexion. Numo n’exécute pas de code : le serveur de référence n’a besoin d’aucun runner de code ni d’aucune sandbox, et aucun service ne reçoit le socket Docker. Les réglages laissés par une release antérieure, comme AGENT_EXECUTION_BACKEND, AGENT_RUNNER_URL, AGENT_RUNNER_SECRET, AGENT_CONTROL_ORIGIN et les identifiants Vercel Sandbox, sont ignorés ; retirez-les de l’environnement protégé.

Exposer les origines publiques et exécuter les tâches planifiées

Une installation publique exige un proxy TLS et une redirection HTTP vers HTTPS. Origines applicative et Supabase, redirections Auth, callbacks OAuth et en-têtes transmis doivent correspondre. Gardez PostgreSQL, Studio et ports internes hors d’Internet. En full, l’application appelle http://kong:8000 en interne ; le navigateur et les liens générés conservent l’origine publique Supabase. HTTP privé exige localhost ou une IPv4 privée de confiance, sans redirection de ports du routeur.

Fournir une planification authentifiée

Les profils Compose de référence démarrent leur planificateur et génèrent CRON_SECRET. Un déploiement personnalisé depuis les sources doit fournir un planificateur HTTP équivalent. Chaque requête envoie Authorization: Bearer <CRON_SECRET> ; une valeur vide ou incorrecte retourne 401. Ne journalisez pas cet en-tête. Les horaires ci-dessous sont en UTC et appartiennent à cette version. Utilisez l’ensemble de la version déployée : les routes peuvent évoluer avec l’application.

Par rapport au scheduler de la v0.11.0, cette version ajoute numo-turns, forge-relay-maintenance, page-materialization et issue-index, et n’appelle plus /api/cron/agent-drain ni /api/cron/automations, retirés avec le travail de code de Numo et les automatisations de projet. Un scheduler personnalisé copié depuis la v0.11.0 doit être mis à jour selon ce tableau.

Arrêter les jobs en maintenance

Arrêtez planificateur, application, workers et accès public Supabase avant sauvegarde ou migration. L’arrêt de l’application seule autorise encore des écritures API directes. Effectuez les contrôles de maintenance pendant que jobs et entrée publique restent fermés, puis rouvrez après validation de la base, Auth, Storage et application. Pour un job inactif, vérifiez en privé état du planificateur, origine canonique et secret. Les routines exigent le planificateur serveur, sans application desktop ouverte.