Integrationen & Runtime Profiles
Ein Runtime Profile ist die benannte MCP-Serverauswahl für einen Workflow. Es ist die Quelle, die LightNow für Client-Sync, LightNow-Proxy-Auflösung und Runtime-Prüfung verwendet. Baue diese Auswahl einmal auf, statt dieselben Serverdefinitionen in jede AI-Client-Datei zu kopieren.
Das Profilmodell verstehen
Jeder Workspace besitzt ein default-Profil. Abhängig von Plan und Kontext
kannst du weitere persönliche oder Organisationsprofile anlegen, etwa für
Platform Engineering, Frontend-Entwicklung oder Incident Response.
Ein Profil beantwortet vier operative Fragen:
- Welche MCP-Server gehören zu diesem Workflow?
- Unter welchem Alias ist jeder Server im Profil erreichbar?
- Welche Runtime Inputs oder Secret-Referenzen fehlen noch?
- Welche Clients und Organisationsregeln sollen das Profil verwenden?
Persoenliche Profile gehoeren dir. Organisationsprofile werden im Team geteilt.
Kombiniere Registry-Server, importierte Eintraege und eigene Server mit stabilen Aliasen.
Ergaenze Commands, URLs, Header und Secret-Referenzen, die die Server brauchen.
Nutze zuerst Local Proxy; Direct Sync oder Runner nur, wenn ein Client es braucht.
- Managed Mode
- laesst Policy Sync den Local-Proxy-Pfad waehlen
- Profil
- bestimmt das Server-Set fuer Clients
- Client-Rollout
- startet mit einem Pilot-Client
- Cleanup
- macht direkte Eintraege sichtbar oder entfernt sie
- Runtime Events
- liefern Metadaten fuer Analyze
- Policy-Phase
- erst beobachten, spaeter erzwingen
Ein ausführbares Profil aufbauen
Öffne Config, um ein Profil auszuwählen, Registry-Server oder Custom Server hinzuzufügen und unterstützte Einträge aus einer bestehenden Client-Config zu importieren. Das Entfernen eines Servers aus dem Profil löscht nicht dessen Registry-Eintrag.
Nutze den persönlichen Kontext für dein eigenes Setup. Wähle eine Organisation, bevor du ein Profil bearbeitest, das von ihr geteilt und verwaltet werden soll.
Nutze default für die alltägliche Serverauswahl. Lege ein benanntes Profil
an, wenn ein Workflow bewusst andere Server oder eine andere Zugriffsgrenze
benötigt.
Nutze nach Möglichkeit bewertete Registry-Server. Importiere zuerst die bestehende Config, wenn ein Client nützliche Custom Entries enthält.
Ergänze Commands, URLs, Header, Umgebungswerte oder Secret-Referenzen, bevor du das Profil exportierst oder mit einem Client verbindest.
Das Profil ist aktiv, der Plan erlaubt es und die richtigen Personen haben Zugriff.
Default bleibt aktiv; Teamzugriff ist explizitRegistry-, Import- und Custom-Eintraege haben stabile Aliase und passen zur Allowlist.
leere Allowlist bedeutet: alle Server im ScopeEnv, Header, Argumente, URLs und Secret-Metadaten blockieren den Start nicht mehr.
Server haben die Werte, die sie brauchenLightNow kann das Client-Format mit Platzhaltern oder erlaubtem Plaintext rendern.
blockiert, bis jeder Server bereit istLocal Proxy, Direct Sync oder Runner passt zum gewaehlten Client-Workflow.
config-status bestaetigt den managed Zustand- deaktiviertes Profil
- Plan- oder Team-Gate
- fehlender Runtime-Input
- unvollstaendiger Custom Server
- Plaintext per Policy gesperrt
- aktives Profil
- stabile Aliase
- Server-Inputs aufgeloest
- platzhalter-sichere Ausgabe
- Client-Status beobachtet
Ein gespeichertes Profil ist nicht automatisch ausführbar. Behandle fehlende Inputs und Config-Fehler als Blocker, bevor du Client-Dateien änderst.
Runtime-Material aus Client-Dateien heraushalten
Die Profil-Config beschreibt, wie ein Server ausgeführt werden soll. Secret-Werte können als verwaltete Werte oder externe Referenzen gespeichert und nur für einen autorisierten Runtime-Pfad aufgelöst werden. Beim normalen LightNow-Proxy-Sync landet ein Proxy-Eintrag in der Client-Datei, nicht jeder Server und jedes Secret.
Ein Direct Export verhält sich anders: Er schreibt client-native Servereinträge und kann Werte entsprechend dem ausgewählten Secret-Modus materialisieren. Nutze ihn nur, wenn Client oder Deployment bewusst dieses Dateiformat benötigen.
Konfiguriere Commands, Header, Umgebungswerte und Secret-Referenzen, ohne sie in normalen Prüfpfaden offenzulegen.
Prüfe Merge- und Replace-Verhalten, bevor du das Zielprofil änderst.
Einen Client verbinden und prüfen
Erprobe das Profil über die CLI zunächst mit einem Pilot-Client. Lasse
--tenant weg, wenn du im persönlichen Kontext arbeitest oder der
Organisationskontext bereits gespeichert ist.
lightnow context --tenant acme lightnow import-config --client codex --profile platform --dry-run lightnow import-config --client codex --profile platform lightnow sync --client codex --profile platform --local-proxy lightnow config-status --client codex --json lightnow-proxy --config ~/.lightnow/lightnow-proxy/codex.yaml --health --json
Überspringe den Import, wenn keine bestehende Client-Config erhalten werden
muss. Ein erfolgreiches config-status bestätigt die erwartete Dateiposture.
Der Proxy-Health-Command löst das Profil aktiv auf und prüft seine Upstreams.
Managed-Client-Policy anwenden
Nach einem erfolgreichen Pilot können Organisationseinstellungen festlegen:
- ob LightNow Proxy aktiviert ist,
- welches Runtime Profile der Organisationsstandard ist,
- welche unterstützten Clients verwaltet werden,
- ob nicht verwaltete MCP-Einträge bleiben dürfen und
- ob reine Metadaten-Telemetrie aktiviert ist.
Wende diese Einstellungen so an:
lightnow sync --client codex --from-settings
Ist der Client verwaltet und der Proxy-Modus aktiviert, schreibt die CLI das von der Organisation ausgewählte LightNow-Proxy-Setup. Blockiert die Policy nicht verwaltete Einträge, entfernt der Sync diese aus der MCP-Config des verwalteten Clients.
Verstehen, was lokal bleibt
Die AI-Client-Datei und die client-spezifische LightNow-Proxy-Config bleiben auf dem Host, auf dem der Client läuft. Dort laufen auch lokale stdio-Upstreams. LightNow speichert Profil, nicht geheime Config, Secret-Status oder Referenzen, Policy und reine Metadaten-Events im ausgewählten Kontext.