Regionen
Regionen — Überblick
Eine Region betreibt den Gateway-Stack nah an der Umgebung, die er schützt.
Eine Region ist ein Outgate-Gateway-Deployment, das Sie in der Umgebung betreiben, in der Traffic behandelt werden soll. Statt alle Anfragen über ein gemeinsames gehostetes Gateway zu schicken, können Sie Gateway, Guardrail-Service, Logging-Service, Launchpad und Region-Agent nah an Ihren Anwendungen und Daten platzieren.
Die globale Console bleibt die Steuerungsebene. Sie legt den Region-Eintrag an, generiert die Deployment-Konfiguration, sendet Befehle und zeigt Status. Die Region selbst übernimmt Routing, Guardrail-Validierung, Logging, Metriken und die Health der lokalen Services.
Diese Trennung hält die operative Steuerung zentralisiert, lässt Laufzeit-Traffic aber in der von Ihnen deployten Region.
Was eine Region betreibt
Der generierte Stack umfasst Gateway, Redis, Log-Manager, Guardrail, Launchpad und Region-Agent.
Wenn Sie ein Region-Deployment herunterladen, generiert Outgate einen Docker-Compose-Stack für die Services des regionalen Gateways.
| Service | Rolle |
|---|---|
| Gateway | Empfängt Client-Traffic, authentifiziert Gateway-Shares, wendet Gateway-Policies an und leitet Anfragen nach upstream weiter. |
| Gateway-Datenbank und Migration | Speichert die Gateway-Konfiguration und bereitet das Schema vor, bevor das Gateway startet. |
| Redis | Speichert regionale Logs, Metriken-Aggregate, Guardrail-Konfiguration, Detection-State und Laufzeit-Koordinationsdaten. |
| Log-Manager | Sammelt Gateway-Logs und -Metriken, bedient regionale Log-Queries und speichert den Guardrail-Policy-State, den der Gateway-Pfad nutzt. |
| Guardrail-Service | Validiert Request-Inhalte, erkennt PII und Zugangsdaten und liefert Block- oder Anonymisierungs-Entscheidungen. |
| Launchpad | Verwaltet den Lifecycle regionaler Sandboxes und Chat-Threads, vermittelt Sandbox-In- und -Output und speichert Thread-State über Redis. |
| Region-Agent | Empfängt Console-Befehle, konfiguriert regionale Services, verwaltet Gateway-Routen und -Plugins und sendet Health-Heartbeats. |
Die generierte Environment-Datei enthält Identifier für Region und Organisation, ein Webhook-Geheimnis, einen internen API-Key, Passwörter für Datenbank und Redis sowie alle Verbindungseinstellungen, die der gewählte Region-Modus benötigt.
Eine Region anlegen
Beim Anlegen werden Control-Plane-Eintrag und Deployment-Credentials vorbereitet.
Regionen werden in der Console von einem Org-Owner oder -Administrator angelegt. Aktuell setzt das einen Pro-Plan mit angenommener Pro-Lizenz voraus, bevor eine Region angelegt werden kann.
Beim Anlegen erzeugt Outgate eine Region-ID, ein Webhook-Geheimnis und einen internen API-Key. Diese Werte verbinden den deployten Stack mit der Steuerungsebene und sind in der generierten Konfiguration enthalten, mit der Sie die Region deployen.
Für öffentliche Regionen geben Sie eine Region-URL an, die die Steuerungsebene erreichen kann. Für private Regionen erstellt Outgate die Queue und die zugehörigen Credentials für reines ausgehendes Befehls-Polling.
Private und öffentliche Konnektivität
Regionen können Befehle per signierter HTTP oder via SQS-Polling empfangen.
Outgate unterstützt zwei Konnektivitäts-Modelle für Steuerungs-Befehle. Das Laufzeitverhalten des Gateways ist in beiden Modi gleich; der Unterschied liegt darin, wie Konfigurationsänderungen den Region-Agent erreichen.
| Modus | Wie Befehle ankommen | Wann nutzen |
|---|---|---|
| Privat | Der Region-Agent pollt eine AWS-SQS-FIFO-Queue per Long-Poll und schickt signierte Callbacks an die Steuerungsebene zurück. | Die Region steht hinter einer Firewall, NAT oder einem privaten Netzwerk und soll keinen eingehenden Befehlstraffic akzeptieren. |
| Öffentlich | Die Steuerungsebene schickt HMAC-signierte HTTP-Befehle an den Region-Agent-Endpoint. | Die Region hat einen stabilen öffentlichen Endpoint, den die Steuerungsebene erreichen kann. |
Der private Modus ist von der Region aus nur ausgehend. Der Region-Agent pollt seine Queue, führt Befehle lokal aus und postet signierte Ergebnisse an die Steuerungsebene zurück. Im öffentlichen Modus akzeptiert der Region-Agent signierte Befehlsanfragen und prüft die Signatur, bevor er sie ausführt.
Beide Modi nutzen signierte Callbacks und signierte Heartbeats, sodass die Steuerungsebene überprüfen kann, dass Updates aus der erwarteten Region kommen.
Den Stack deployen
Die Console liefert Docker-Compose- und Environment-Konfiguration für die Region.
Nachdem eine Region angelegt ist, kann die Console die Docker-Compose-Datei und die Environment-Konfiguration für diese Region generieren. Die Dateien sind spezifisch für Organisation, Region-ID, Konnektivitäts-Modus und generierte Geheimnisse.
Der Stack startet das Gateway, führt die Gateway-Datenbank-Migration aus, startet Redis und bringt anschließend Log-Manager, Guardrail-Service, Launchpad und Region-Agent hoch. Der Region-Agent stellt zudem sicher, dass benötigte Gateway-Erweiterungen vorhanden sind, einschließlich Request-Korrelation und globaler Outgate-Key-Extraktion.
Öffentliche Regionen enthalten HTTP-Befehlseinstellungen und den Region-Endpoint in der generierten Environment. Private Regionen enthalten die AWS- und SQS-Einstellungen für das Befehls-Polling.
Befehlsfluss
Der Region-Agent setzt Console-Aktionen in lokale Gateway-Konfigurationsänderungen um.
Die meisten Region-Operationen beginnen als Befehle aus der Steuerungsebene. Provider anlegen, Shares aktualisieren, Gateway-Konfiguration ändern, Chat-Sessions verwalten und ähnliche Aktionen werden an den Region-Agent ausgeliefert, der sie auf die in der Region laufenden Services anwendet.
Im privaten Modus schreibt die Steuerungsebene Befehle in die Region-SQS-Queue. Der Agent pollt die Queue per Long-Poll, leitet jeden Befehl an den passenden lokalen Handler und schickt einen signierten Callback, sobald der Befehl abgeschlossen ist oder fehlschlägt.
Im öffentlichen Modus schickt die Steuerungsebene einen signierten HTTP-POST an den Region-Agent. Der Agent prüft die Signatur, führt den Befehl aus und gibt das Ergebnis über denselben Befehlspfad zurück.
So bleibt jede direkte Service-Mutation innerhalb der Region. Die Console entscheidet, was sich ändern soll, aber der Region-Agent ist verantwortlich, diese Änderungen lokal anzuwenden.
Für Chat- und Sandbox-Operationen leitet der Region-Agent Befehle an Launchpad weiter. Launchpad verantwortet den regionalen Thread-Lifecycle, startet Sandbox-Container, vermittelt Nachrichten und hält den Stream-State, der zum Wiederaufnehmen oder Inspizieren von Sessions nötig ist.
Heartbeats und Health
Regionen melden Service-Health, Versionen, Uptime und Rotationsstand zurück an die Console.
Der Region-Agent schickt regelmäßig signierte Heartbeats an die Steuerungsebene. Ein Heartbeat enthält die Region-Identität, Service-Versionen, Stack-Status, Uptime, Heartbeat-Intervall und — sofern konfiguriert — den öffentlichen Endpoint.
Vor dem Senden des Heartbeats prüft der Agent den lokalen Stack — Gateway, Log-Manager und Guardrail-Service. Die Console nutzt diese Daten, um anzuzeigen, ob die Region verbunden und gesund ist.
Heartbeats unterstützen auch die Credential-Rotation. Die Steuerungsebene kann aktualisierte Webhook-Geheimnisse oder AWS-Credentials zurückgeben, und der Region-Agent übernimmt diese Updates für künftige Kommunikation.
Guardrail-LLM-Konfiguration
Der regionale Guardrail-Service hat eine eigene Modell-Konfiguration.
Der Guardrail-Service läuft innerhalb der Region und kann mit eigenen LLM-Settings konfiguriert werden. Dieses Modell wird für die Guardrail-Analyse genutzt und ist unabhängig von den Upstream-Providern, die Anwendungstraffic behandeln.
Die generierte Environment enthält die Guardrail-LLM-Konfiguration, sodass der Service das von Ihnen gewählte Modell zur Validierung erreichen kann. In lokalen oder privaten Deployments zeigen Teams das oft auf einen lokalen oder internen Modell-Endpoint. In anderen Deployments kann ein OpenAI-kompatibler Endpoint genutzt werden.
Weil die Guardrail-Auswertung in der Region passiert, können sensible Request-Inhalte inspiziert und anonymisiert werden, bevor irgendeine Anwendungsanfrage nach upstream geht.
Daten- und Betriebsgrenzen
Laufzeit-Logs und Guardrail-State bleiben im regionalen Stack.
Regionen sind so entworfen, dass Laufzeit-Gateway-Daten von den regionalen Services behandelt werden. Request-Logs, Response-Metadaten, Metriken, Guardrail-Entscheidungen und Detection-State liegen im regionalen Redis und werden vom regionalen Log-Manager bedient.
Die Console kann regionale Daten über die Region-APIs lesen — der Anfragepfad, der Logging-Pfad und der Guardrail-Pfad leben aber in der deployten Region. Genau diese Grenze erlaubt einem Team, ein Gateway nah an den Anwendungen und Daten zu betreiben, die es schützt.
Die globale Steuerungsebene speichert weiterhin den Region-Eintrag, den Befehlsstatus, Konnektivitäts-Metadaten und die Konfiguration zur Verwaltung der Region. Sie ersetzt die lokalen Services, die Laufzeit-Traffic verarbeiten, nicht.
Betriebsaspekte
Behandeln Sie eine Region als Infrastruktur mit erreichbaren Abhängigkeiten und überwachter Health.
Eine Region hängt davon ab, dass ihre lokalen Services in der erwarteten Reihenfolge starten. Das Gateway braucht Datenbank und Migration, Gateway-Erweiterungen müssen installiert sein, Redis muss für Logs, Guardrail-State und Launchpad-Thread-State verfügbar sein, und der Guardrail-Service braucht Zugriff auf das konfigurierte Analyse-Modell.
Private Regionen hängen zusätzlich von SQS-Zugriff und gültigen, eingegrenzten AWS-Credentials ab. Öffentliche Regionen hängen von einem stabilen Endpoint ab, der signierte Steuerungs-Befehle empfangen kann.
Heartbeats sind das Hauptsignal dafür, ob die Steuerungsebene die Region noch verwalten kann. Bleiben Heartbeats aus, bedient das Laufzeit-Gateway lokal womöglich weiter Traffic — die Console hat dann aber keinen aktuellen Blick auf Health oder Befehlsfortschritt.
Alles zusammengeführt
Regionen halten den Gateway-Pfad lokal und bewahren zentrale Steuerung.
Sobald eine Region deployt ist, schicken Ihre Anwendungen Traffic an das regionale Gateway. Das Gateway authentifiziert die Anfrage, wendet Guardrails an, routet zum gewählten Provider und schreibt Logs und Metriken im regionalen Stack.
Die Console bleibt der Ort, an dem Teams Regionen anlegen, Status prüfen, Konfigurationsbefehle senden und operative Daten inspizieren. Der Region-Agent verbindet diese Steuerungs-Aktionen mit den lokalen Gateway-Services.
Das gibt Teams eine einzige Steuerungsoberfläche für Outgate — und hält den Anfragepfad nah an den Systemen, die ihn nutzen.