Instanzkonfiguration

Die Instanzkonfiguration legt öffentliche Origins, Geheimnisse und verfügbare Dienste fest. Sichern Sie vorhandene Zugangsdaten, bevor Sie die geschützte Umgebung ändern. Konfigurieren Sie jeden optionalen Anbieter vollständig und prüfen Sie danach die Netzwerkfreigaben und authentifizierten geplanten Jobs.

Origins, Geheimnisse und Funktionen der Instanz konfigurieren

MINDDY_PUBLIC_APP_URL muss ein einzelner absoluter Origin ohne Pfad oder abschließenden Schrägstrich sein. Öffentliche Installationen verwenden HTTPS; localhost und vertrauenswürdige private IPv4 dürfen HTTP verwenden. MINDDY_PUBLIC_SUPABASE_URL und MINDDY_PUBLIC_SUPABASE_ANON_KEY müssen denselben Supabase-Stack bezeichnen. Diese Werte erreichen den Browser. SUPABASE_SERVICE_ROLE_KEY bleibt ausschließlich serverseitig und ist in Produktion erforderlich. Er darf nie in öffentliche Variablen oder Clientbundles gelangen. Eine Datenbank-URL dient Werkzeugen und ersetzt nicht die API-Konfiguration.

Geheimnisse erhalten

Der Installer ergänzt fehlende GIT_STATE_SECRET, GIT_TOKEN_ENCRYPTION_SECRET, AI_KEY_ENCRYPTION_SECRET, FEEDBACK_SSO_ENCRYPTION_SECRET, MINDDY_DATA_ROOT_KEY und CRON_SECRET. Der Inhaltswurzelschlüssel besteht aus genau 64 Hexadezimalzeichen. Bewahren Sie ihn außerhalb PostgreSQL mit geschützter Wiederherstellungskopie auf. Die gesamte Umgebung benötigt Modus 0600 und darf nicht in Git gelangen. Führen Sie sie nicht als Shell-Code aus und geben Sie sie nicht aus. Ein Installationswiederholungsversuch rotiert keine Geheimnisse. Schlüsselverlust kann vorhandene Daten unlesbar machen; absichtliche Rotation benötigt das passende Wiederherstellungsverfahren.

Änderungen anwenden und prüfen

MINDDY_PUBLIC_SITE_NAME und MINDDY_PUBLIC_CONTACT_EMAIL kennzeichnen Ihre Instanz. ADMIN_EMAILS enthält kommagetrennte Administratoradressen; privilegierter Zugriff verlangt zusätzlich MFA. OAUTH_ISSUER bleibt normalerweise leer, außer OAuth soll bewusst über einen anderen stabilen Origin angeboten werden. Lassen Sie verwaltete KI und Abrechnung beim Selbsthosting aus. Optionale Dienste benötigen ihre vollständige Konfiguration. Starten oder erstellen Sie die Anwendung nach Änderungen öffentlicher Laufzeitwerte neu; ein OCI-Neubuild ist unnötig. doctor unterscheidet unvollständige Funktionen von Kernfehlern. Testen Sie danach Kontolinks und Callbacks am vorgesehenen Origin.

Feedback und Dokumentationsmeldungen konfigurieren

Setzen Sie MINDDY_FEEDBACK_KEY auf einen Feedback-Integrationsschlüssel, um die Feedback-Funktion in der App zu aktivieren. Erstellen Sie für Dokumentationsmeldungen eine eigene Feedback-Integration im empfangenden Projekt, wählen Sie Documentation als Standardziel und speichern Sie den Schlüssel als MINDDY_DOCUMENTATION_FEEDBACK_KEY. Beide Schlüssel bleiben auf dem Server. Meldungen werden an /api/v1/feedback unter dem mit MINDDY_PUBLIC_APP_URL festgelegten Ursprung gesendet. Starten Sie die Anwendung nach Änderungen dieser Werte neu.

Um über einen Artikel einen Fehler zu melden, ist ein angemeldetes Konto erforderlich. Nach der Anmeldung kehrt der Leser zum selben Artikel zurück; der Feedback-Dialog ist geöffnet. Titel und Beschreibung sind zunächst leer. Nach dem Absenden ergänzt der Server die Artikel-ID, Sprache, Revision und öffentliche URL. Diese Angaben sind keine bearbeitbaren Formularfelder. Die Dokumentationsintegration verknüpft das Feedback automatisch mit dem ausgewählten Ziel. Ohne MINDDY_DOCUMENTATION_FEEDBACK_KEY ist die Schaltfläche zum Melden von Fehlern deaktiviert und zeigt eine Erklärung an.

Optionale Anbieter bewusst einschalten

Der Kern benötigt weder Stripe, PostHog, Cloud-Konto noch einen von minddy verwalteten KI-Schlüssel. Externe Dienste bringen eigene Kosten, Rechte und Datenziele. Prüfen Sie Bedingungen vor Aktivierung. Diagnosen melden fehlende Werte statt eines Ersatzanbieters. Selbsthosting kann persönliche KI-Schlüssel oder erreichbare lokale KI-Endpunkte nutzen. Lassen Sie MINDDY_MANAGED_AI und MINDDY_MANAGED_BILLING aus; ein OpenRouter-Schlüssel allein wählt keine Cloud-Edition.

Vollständige Anbieterwerte setzen

Anwendungsmail braucht EMAIL_PROVIDER=resend, RESEND_API_KEY, FEEDBACK_EMAIL_FROM und INVITATION_EMAIL_FROM. console ist in Produktion unzulässig; Auth-SMTP bleibt getrennt. Web Push benötigt öffentliches/privates VAPID-Paar und VAPID_SUBJECT; bestehende Abonnements hängen von diesem Paar ab. Analytics braucht ein vollständiges PostHog-Schlüssel/Host-Paar; Fehlertracking zusätzlich MINDDY_PUBLIC_ERROR_TRACKING=1. Der Installer bietet application-email und web-push, externe Zugangsdaten liefern Sie. Nutzen Sie keine minddy-Absenderidentitäten oder nativen Release-Zugangsdaten auf fremden Instanzen.

Git und Codeausführung verbinden

Unterstützt werden GitHub.com und GitLab.com, nicht Enterprise Server oder selbstverwaltetes GitLab. Benutzerinitiierte Verbindungen können den verwalteten Forge-Relay nutzen; deaktivieren Sie ihn mit --no-forge-relay oder MINDDY_FORGE_RELAY=0 und konfigurieren Sie eigene Apps. Bestehende Verbindungen behalten ihren Kanal bis zur Neuverbindung. Numo führt keinen Code aus. Der Referenzserver benötigt daher weder Code-Runner noch Sandbox, und kein Dienst erhält den Docker-Socket. Einstellungen aus einer früheren Release, etwa AGENT_EXECUTION_BACKEND, AGENT_RUNNER_URL, AGENT_RUNNER_SECRET, AGENT_CONTROL_ORIGIN und die Zugangsdaten für Vercel Sandbox, werden ignoriert; entfernen Sie sie aus der geschützten Umgebung.

Öffentliche Origins und geplante Aufgaben betreiben

Öffentliche Installationen benötigen TLS-Proxy und HTTP-zu-HTTPS-Weiterleitung. Anwendungs- und Supabase-Origin, Auth-Weiterleitungen, OAuth-Callbacks und weitergereichte Header müssen übereinstimmen. PostgreSQL, Studio und interne Ports bleiben vom Internet getrennt. Im full-Profil verwendet die Anwendung intern http://kong:8000, Browser und erzeugte Links behalten den öffentlichen Supabase-Origin. Privates HTTP verlangt localhost oder vertrauenswürdige private IPv4 ohne Router-Portweiterleitungen.

Authentifizierte Zeitpläne bereitstellen

Referenz-Compose startet den Scheduler und erzeugt CRON_SECRET. Eigene Quellcodebereitstellungen brauchen einen gleichwertigen HTTP-Scheduler. Jede Anfrage sendet Authorization: Bearer <CRON_SECRET>; ein leeres oder falsches Geheimnis ergibt 401. Protokollieren Sie den Header nicht. Die folgenden Zeitpläne verwenden UTC und gehören zu dieser Version. Verwenden Sie den Satz der installierten Version, denn Pfade können sich ändern.

Gegenüber dem Scheduler von v0.11.0 fügt diese Version numo-turns, forge-relay-maintenance, page-materialization und issue-index hinzu und ruft /api/cron/agent-drain und /api/cron/automations nicht mehr auf; beide wurden mit Numos Codearbeit und den Projektautomatisierungen entfernt. Ein aus v0.11.0 kopierter eigener Scheduler muss an diese Tabelle angepasst werden.

Jobs während Wartung stoppen

Stoppen Sie vor Backup oder Migration Scheduler, Anwendung, Worker und öffentlichen Supabase-Zugang. Das Stoppen allein der Webanwendung erlaubt weiterhin direkte API-Schreibzugriffe. Prüfen Sie Wartung bei geschlossenen Jobs und Zugängen und öffnen Sie erst nach Datenbank-, Auth-, Storage- und Anwendungstests. Prüfen Sie bei inaktiven Jobs Scheduler, kanonischen Origin und Geheimnis privat. Routinen benötigen den Serverscheduler, keine dauerhaft geöffnete Desktop-App.