Betrieb

Diese Seite richtet sich an alle, die einen Brio-IO-Server betreiben. Sie ist bewusst schlank: Sie beschreibt die Stellschrauben, die es heute gibt.

Zum Bezug: Brio-IO ist im Early Access. Es gibt keinen öffentlichen Self-Service-Download; Zugänge und Installationspakete richten wir persönlich ein. Frag uns nach einem Zugang — schreib kurz dazu, welche Schnittstellen du integrieren willst.

Aufbau eines Deployments

Ein Brio-IO-Deployment besteht aus drei Teilen:

• Brio-IO Server — die headless laufende Anwendung. Sie hält die Channels, die Connectoren und die Laufzeit.
• PostgreSQL — der Nachrichtenspeicher. Schema-Migrationen fährt der Server beim Start selbst.
• Brio-IO UI — die Weboberfläche. Sie ist ein eigenes Deployment und wird nicht in den Server gepackt: Ein UI kann mehrere Server bedienen (Server-Auswahl in der Oberfläche), etwa Produktion, Staging und Test in einer Konsole.

Konfiguration: Profile und Umgebungsvariablen

Der Server nutzt Spring-Profile. Ausgeliefert werden unter anderem brio-dev (Standard) und brio-staging; sie unterscheiden sich in den Vorgaben für Datenbank, Konfigurationspfad und Log-Level. Alles Betriebsrelevante lässt sich über Umgebungsvariablen setzen.

Datenbank

Variable	Bedeutung
BRIO_DATASOURCE_URL	JDBC-URL der PostgreSQL-Instanz
BRIO_DATASOURCE_USERNAME	Datenbank-Benutzer
BRIO_DATASOURCE_PASSWORD	Datenbank-Passwort

Konfigurations-Repository

Variable	Bedeutung
BRIO_CONFIG_REPO_PATH	Verzeichnis des Git-Konfigurationsrepositories

Standard ist ./data/config-repo (Entwicklung) bzw. /var/lib/brio/config-repo (Staging-Profil). Dieses Verzeichnis ist die Konfiguration — Channels, Connectoren, Skripte, Code-Templates. Es gehört in die Sicherung, und zwar als Git-Repository, nicht als Dateikopie.

Anmeldung und Tokens

Variable	Bedeutung
BRIO_AUTH_MODE	local, oidc oder both (Standard: local)
BRIO_ADMIN_USERNAME	Name des initialen Administrators (Standard: admin)
BRIO_ADMIN_PASSWORD	Passwort des initialen Administrators
BRIO_JWT_ACCESS_TTL	Lebensdauer des Access-Tokens (Standard: 15 Minuten)
BRIO_JWT_REFRESH_TTL	Lebensdauer des Refresh-Tokens (Standard: 8 Stunden)

Die Voreinstellungen für die Token-Laufzeiten sind bewusst so gewählt: Ein kurzlebiges Access-Token, das die Oberfläche selbstständig erneuert, und ein Refresh-Token, das eine Schicht abdeckt — damit sich niemand mitten in der Arbeit neu anmelden muss.

Für OIDC (BRIO_AUTH_MODE=oidc oder both) gibt es die üblichen Stellschrauben: BRIO_OIDC_ISSUER_URI, BRIO_OIDC_CLIENT_ID, BRIO_OIDC_CLIENT_SECRET, BRIO_OIDC_AUDIENCE sowie BRIO_OIDC_ROLE_CLAIM für den Pfad zu den Rollen im Token (Keycloak legt sie unter realm_access.roles ab, Azure AD in einem roles-Anspruch auf oberster Ebene). both lässt die lokale Anmeldung als Rückfallweg bestehen — sinnvoll, solange der Identity-Provider noch nicht als alleiniger Zugang erprobt ist.

Branch-Engine

Variable	Bedeutung
BRIO_BRANCH_ENGINE_ENABLED	Branch-Engine an/aus (Standard: an)
BRIO_BRANCH_ENGINE_MAX	maximale Zahl gleichzeitiger Shadow-Engines (Standard: 5)
BRIO_BRANCH_ENGINE_MAX_MESSAGES	Obergrenze gespeicherter Shadow-Nachrichten (Standard: 100 000)
BRIO_BRANCH_ENGINE_PURGE_ON_MERGE	Shadow-Daten beim Merge aufräumen (Standard: an)
BRIO_BRANCH_ENGINE_PURGE_ON_DELETE	Shadow-Daten beim Löschen eines Branches aufräumen (Standard: an)
BRIO_BRANCH_ENGINE_MAX_DIFF_EXAMPLES	Zahl konkreter Abweichungs-Beispiele in der Merge-Zusammenfassung (Standard: 20; 0 = nur Zählwerte)

Die beiden Obergrenzen sind der Grund, warum Shadowing den Server nicht langsam volllaufen lässt: Shadow-Verkehr ist Diagnose-Material mit begrenzter Haltbarkeit, kein zweiter Produktivbestand.

Lizenz

Variable	Bedeutung
BRIO_LICENSE_KEY	Lizenzschlüssel des Deployments
BRIO_LICENSE_SECRET	Signaturgeheimnis zur Lizenzprüfung

BRIO_LICENSE_SECRET muss in Produktion gesetzt werden. Der eingebaute Vorgabewert ist ausdrücklich nur für Entwicklung gedacht.

Health und Info

Der Server stellt Actuator-Endpunkte bereit:

curl -s http://localhost:8080/actuator/health

• health liefert den Zustand; Details erscheinen nur für berechtigte Aufrufer.
• info enthält Build- und Git-Angaben — nützlich, um zu prüfen, welcher Stand tatsächlich läuft. Genau diese Frage ist der häufigste Grund für falsche Diagnosen nach einem Deploy.

Der JMS-Health-Indicator ist bewusst abgeschaltet: JMS-Konnektivität ist bei Brio-IO eine Eigenschaft einzelner Channels, kein Lebenszeichen des Prozesses. Ohne diese Abschaltung würde ein fehlender Broker den gesamten Server als DOWN melden.

API-Dokumentation

Die REST-API ist Spec-First: Die maßgebliche OpenAPI-Beschreibung ist ein gepflegtes Dokument, das der Server unter /api/docs ausliefert. Eine Swagger-Oberfläche liegt unter /swagger-ui.html und lädt genau diese Spec.

Eine vollständige API-Referenz ist nicht Teil dieser Dokumentation — die Spec am Server ist die aktuellere Quelle.

Logging

Log-Level je Umgebung: DEBUG für io.brio im Entwicklungsprofil, INFO im Staging-Profil. Beim Deployment eines Channels lohnt ein Blick ins Log — dort erscheinen zwei Warnungen, die man ernst nehmen sollte:

• Deprecation-Warnung, wenn der Channel mindestens ein js-legacy-Skript enthält, mit Namen der betroffenen Skripte.
• Warnung auf veraltete Datentyp-Pfade in Skripten (XPN_1, FN_1 …), die heute still einen leeren String liefern würden. Siehe Konzepte.

Sicherung

Zwei Dinge sind zu sichern, und sie sind unterschiedlicher Natur:

1. Das Konfigurations-Repository (BRIO_CONFIG_REPO_PATH) — die Wahrheit über deine Channels. Am besten als Git-Remote, dann ist die Sicherung zugleich die Historie.
2. Die PostgreSQL-Datenbank — der Nachrichtenspeicher.

Ein Server lässt sich aus dem Konfigurations-Repository allein wieder aufbauen; die Datenbank trägt die verarbeiteten Nachrichten, nicht die Konfiguration.