Open Connector für KI-Agenten selbst hosten

Was Open Connector für einen KI-Agenten leistet

Self-Hosting von Open Connector setzt ein Authentifizierungs-Gateway zwischen Ihren KI-Agenten und jede von ihnen aufgerufene Software-as-a-Service-(SaaS-)API. Der Agent verwaltet dadurch niemals ein Provider-Token. Open Connector ist ein Open-Source-Gateway von OOMOL Lab und steht unter der Apache-2.0-Lizenz. Es läuft als ein Container, speichert seinen Zustand in einer einzelnen SQLite-Datei und stellt Provider-Aktionen über HTTP sowie über MCP (model context protocol) bereit.

Das Problem beginnt bei der zweiten Integration. Jeder Provider hat seinen eigenen OAuth-(open authorization-)Ablauf, seine eigene Gültigkeitsdauer für Refresh-Tokens und seine eigenen Scope-Namen. Fünf Provider manuell in einen Agenten zu integrieren bedeutet fünf Redirect-Handler, fünf Credential-Speicher und fünf Refresh-Schleifen, die jeweils vor Ablauf eines Tokens ausgeführt werden müssen. Fast niemand schreibt diesen Code. Stattdessen erzeugen Betreiber für jeden Dienst ein langlebiges persönliches Zugriffstoken und fügen es in die Agentenkonfiguration, eine Umgebungsdatei oder sogar direkt in den Prompt ein. Dieses Token kann dann von jedem vom Agenten ausgeführten Tool gelesen werden und landet im Transkript. Genau diesen Fehler beschreibt Geheimnisse aus KI-Agenten heraushalten.

Ein Authentifizierungs-Gateway teilt das Credential in zwei Teile. Das Gateway speichert das Provider-Credential und führt den OAuth-Ablauf aus. Der Agent erhält ein Laufzeit-Token, das nur gegenüber dem Gateway gültig ist. Wenn der Agent eine Aktion aufruft, lädt das Gateway das gespeicherte Credential, fügt es serverseitig in die ausgehende Anfrage ein und gibt nur den Antworttext zurück. Der Agent erhält das Provider-Zugriffstoken nie. Wenn das Agenten-Transkript offengelegt wird, kostet Sie das daher nur ein widerrufbares Laufzeit-Token und nicht Ihr GitHub-Konto.

Der Katalog nennt mehr als 1,000 Provider und 10,000 vorgefertigte Aktionen. Das ist die eigene Angabe des Projekts und lässt sich nicht von außen überprüfen. Überprüfbar ist jedoch die Struktur: ein HTTP-Endpunkt pro Aktion, eine gespeicherte Verbindung pro Provider und ein Token pro Agent.

Warum Open Connector selbst hosten, statt einen gehosteten Connector-Dienst zu verwenden

Ein gehosteter Connector-Dienst erledigt dieselbe Aufgabe. Er speichert die Refresh-Tokens für jeden Provider, den Sie damit verbinden. Ein Refresh-Token für Google oder GitHub ist ein langlebiger kryptografischer Schlüssel für Ihren E-Mail-Zugang und Ihre Repositories. Er bleibt normalerweise auch nach einer Passwortänderung gültig. Wird der Dienst kompromittiert, sind auch Sie betroffen. Beim Self-Hosting liegen diese Datensätze in SQLite auf einer von Ihnen gemieteten und administrierten Maschine. Sie sind mit einem Schlüssel geschützt, der Ihre Maschine nie verlässt.

Machen Sie sich die Kosten bewusst, bevor Sie beginnen. Diese VPS wird zum wertvollsten Server in Ihrer Umgebung. Sie enthält die gültigen Zugangsdaten für ein Dutzend Dienste in einer Datei. Behandeln Sie sie daher wie einen Host für einen Passwort-Manager: Eine Firewall darf nur 443 freigeben, es darf keine gemeinsam genutzten Logins geben, und Sie müssen ein Backup mindestens einmal tatsächlich wiederhergestellt haben. Außerdem brauchen Sie eine Warnung, wenn der Server nicht mehr antwortet. Wenn Sie Ihren Passwort-Tresor nicht auf dieser Maschine speichern würden, sollten Sie dort auch den Connector nicht betreiben.

Installieren Sie nichts, bevor Sie eine Version festgelegt haben

Open Connector ist noch jung. Das Repository wurde erstmals am 29. Juni 2026 veröffentlicht. Am 1. August 2026 ist v1.3.3 das neueste getaggte Release. Es wurde am 30. Juli 2026 veröffentlicht und trägt ebenfalls den latest-Tag. Die Registry veröffentlicht außerdem einen tip-Tag, der aus dem neuesten Commit auf main erstellt wurde.

Bei einem so neuen Projekt ändern sich bewegliche Tags häufig. Ein docker compose pull, das zwei Releases überspringt, kann einen von Ihrem Agent benötigten Endpunkt ändern. Dann verbringen Sie den Abend damit, das Problem fälschlicherweise dem Agent zuzuschreiben. Pinnen Sie das Image auf einen Release-Tag. Aktualisieren Sie es erst, wenn Sie dies bewusst entscheiden und die Release Notes gelesen haben.

Open Connector hinter TLS auf dem eigenen VPS bereitstellen

Bevor der Container startet, benötigen Sie:

• Docker mit dem Compose-Plugin auf Ubuntu 24.04 oder einer vergleichbaren Version
• einen Hostnamen, dessen A-Record auf diesen VPS zeigt, zum Beispiel connect.example.com
• einen Reverse Proxy, der TLS (Transport Layer Security) für diesen Hostnamen bereits terminiert
• zwei zufällige Secrets, die weiter unten generiert werden

Der Traefik-Reverse-Proxy für mehrere Docker-Compose-Anwendungen behandelt die Proxy-Seite. Die vollständige Zertifikatskonfiguration für eine einzelne Anwendung finden Sie im Leitfaden n8n auf einem VPS mit Docker und HTTPS.

Generieren Sie zuerst die Secrets. Der Verschlüsselungsschlüssel schützt die gespeicherten Zugangsdaten. Das Admin-Token schützt die Webkonsole und die gesamte /api-Oberfläche. Für keines der beiden gibt es einen Standardwert. Die Laufzeit startet jedoch auch ohne sie.

mkdir -p ~/open-connector && cd ~/open-connector
umask 077
printf 'OOMOL_CONNECT_ENCRYPTION_KEY=%s\n' "$(openssl rand -base64 32)" > .env
printf 'OOMOL_CONNECT_ADMIN_TOKEN=%s\n' "$(openssl rand -base64 32)" >> .env
chmod 600 .env

Kopieren Sie beide Werte jetzt in Ihren Passwortmanager, bevor Sie den ersten Start durchführen. Für den Verschlüsselungsschlüssel gibt es keinen Wiederherstellungsweg. Der Grund dafür wird weiter unten in der Liste der Fehler beschrieben.

Erstellen Sie jetzt compose.yaml. Diese Datei unterscheidet sich an zwei Stellen vom Beispiel des Upstream-Projekts. Beide Änderungen sind wichtig.

services:
  connector:
    image: ghcr.io/oomol-lab/open-connector:v1.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - connector-data:/app/data
    environment:
      OOMOL_CONNECT_DATA_DIR: /app/data
      OOMOL_CONNECT_ORIGIN: "https://connect.example.com"
      OOMOL_CONNECT_ENCRYPTION_KEY: "${OOMOL_CONNECT_ENCRYPTION_KEY:?set this in .env}"
      OOMOL_CONNECT_ADMIN_TOKEN: "${OOMOL_CONNECT_ADMIN_TOKEN:?set this in .env}"

volumes:
  connector-data:

Die erste Änderung ist der festgelegte Tag anstelle von latest. Die zweite Änderung betrifft den Port. Die Upstream-Datei veröffentlicht 3000:3000 und bindet damit jede Schnittstelle auf dem Host. Docker schreibt veröffentlichte Ports in die NAT-Tabelle (Network Address Translation), bevor das ufw-Filter-Chain das Paket überhaupt sieht. ufw deny 3000 schließt diesen Port daher nicht. Das ist die in warum Docker-Ports ufw umgehen beschriebene Falle. Mit 127.0.0.1:3000:3000 wird der Port nur auf der Loopback-Schnittstelle veröffentlicht. Ihr Reverse Proxy verbindet sich vom selben Host.

:? kennzeichnet jede Variable als erforderlich. Der Stack verweigert daher den Start, wenn .env fehlt, statt mit unverschlüsselten Zugangsdaten zu starten. Die Werte in .env statt in der Compose-Datei zu speichern, entspricht dem Muster aus Docker-Compose-env-Dateien und Secrets.

docker compose up -d
docker compose logs -n 30 connector
curl -s http://127.0.0.1:3000/health
sudo ss -tlnp | grep 3000

/health prüft { "ok": true }, sobald die Laufzeitumgebung aktiv ist. ss muss 127.0.0.1:3000 ausgeben. Eine Zeile mit 0.0.0.0:3000 bedeutet, dass die Portzuordnung noch der Upstream-Zuordnung entspricht und das Gateway direkt aus dem gesamten Internet erreichbar ist. Wenn die Gesundheitsprüfung mit „Connection refused“ endet, lauscht der Container noch nicht. Lesen Sie daher die Logs, bevor Sie den Proxy ändern.

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.connector.rule=Host(`connect.example.com`)"
      - "traefik.http.routers.connector.entrypoints=websecure"
      - "traefik.http.routers.connector.tls.certresolver=le"
      - "traefik.http.services.connector.loadbalancer.server.port=3000"

Warum OAuth einen echten Hostnamen benötigt

OOMOL_CONNECT_ORIGIN ist die Einstellung, die häufig übersprungen wird. Dadurch schlägt OAuth auf eine Weise fehl, die wie ein Fehler des Anbieters wirkt. Die Laufzeitumgebung erstellt daraus die Redirect-URI in der Form <origin>/oauth/callback. Wenn der Wert nicht gesetzt ist, wird als Origin standardmäßig http://localhost:3000 verwendet. Die Laufzeitumgebung sendet dem Anbieter dann die Redirect-URI http://localhost:3000/oauth/callback, während für Ihre OAuth-Anwendung https://connect.example.com/oauth/callback registriert ist. Die beiden Zeichenfolgen unterscheiden sich. GitHub antwortet daher:

The redirect_uri MUST match the registered callback URL for this application.

Ein OAuth-Anbieter leitet den Browser zu dieser URI zurück. Deshalb muss es sich um eine Adresse handeln, die aus dem Internet erreichbar ist. Anbieter lehnen reines http:// für alle Ziele außer localhost ab. Das ist der gesamte Grund, warum diese Bereitstellung einen Hostnamen und ein Zertifikat benötigt. Setzen Sie den Origin vor dem ersten Start, da der Wert beim Start eingelesen wird. Führen Sie nach dem Bearbeiten von .env oder compose.yaml erneut docker compose up -d aus, um die Änderung anzuwenden.

Den ersten Provider über OAuth verbinden

Erstellen Sie zuerst die OAuth-App beim Provider. Bei GitHub lautet der Pfad Settings, dann Developer settings, dann OAuth Apps und anschließend New OAuth App. Setzen Sie die Autorisierungs-Callback-URL auf https://connect.example.com/oauth/callback. Bewahren Sie die Client-ID und das Client-Secret auf.

Jeder Aufruf von /api überträgt das Admin-Token. Exportieren Sie es daher einmal für die Shell-Sitzung.

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

Die Ausgabe zeigt die Redirect-URI, die die Laufzeitumgebung für jeden Provider erwartet. Damit können Sie am schnellsten prüfen, ob der konfigurierte Ursprung übernommen wurde. Wenn weiterhin localhost angezeigt wird, läuft der Container mit dem alten Wert. Der OAuth-Ablauf schlägt dann im letzten Schritt fehl.

Speichern Sie die Client-Zugangsdaten und starten Sie anschließend eine Autorisierung.

curl -s -X PUT https://connect.example.com/api/oauth/configs/github \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"clientId":"...","clientSecret":"..."}'

curl -s -X POST https://connect.example.com/api/oauth/authorizations \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"service":"github"}'

Der zweite Aufruf gibt ein authorizationUrl zurück. Öffnen Sie es in einem Browser und bestätigen Sie die angeforderten Berechtigungen. Der Provider leitet den Browser anschließend zu /oauth/callback zurück. Dort tauscht die Laufzeitumgebung den Code gegen die Zugangsdaten aus und speichert diese. Die Webkonsole unter Ihrem Ursprung führt mit einem Formular durch dieselben Schritte und verwendet dabei dasselbe Admin-Token. Provider, die einen einfachen API-Key verwenden, überspringen diesen Ablauf: PUT /api/connections/<service> mit {"authType":"api_key","values":{"apiKey":"..."}} speichert den Schlüssel direkt.

Jedem Agent ein Laufzeittoken geben, niemals das Zugangstoken

Der Agent authentifiziert sich beim Gateway mit einem Laufzeittoken, das die Admin-API ausstellt.

curl -s -X POST https://connect.example.com/api/runtime-tokens \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"name":"research-agent"}'

Die Antwort enthält ein Token, das mit oct_ beginnt. Stellen Sie für jeden Agenten ein eigenes Token aus und benennen Sie es nach dem jeweiligen Agenten. Wenn Sie ein Token nicht identifizieren können, müssen Sie sonst alle Tokens widerrufen. Der Agent ruft Aktionen anschließend über gewöhnliches HTTP auf.

curl -s -X POST https://connect.example.com/v1/actions/github.get_current_user \
  -H "authorization: Bearer oct_..." \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Eine erfolgreiche Antwort ist ein Envelope, dessen Feld success den Wert true enthält. Die Provider-Nutzlast steht unter data. Das GitHub-Token kommt in dieser Antwort an keiner Stelle vor. Für einen MCP-Client konfigurieren Sie https://connect.example.com/mcp mit demselben Bearer-Header. Das Gateway stellt dann Discovery-Tools wie search_actions und execute_action bereit, statt ein eigenes Tool pro API anzubieten. Dadurch bleibt die Tool-Liste des Agenten klein. MCP-Server auf einem VPS betreiben behandelt die Client-Seite dieser Konfiguration.

Führen Sie eine weitere Prüfung durch, bevor Sie die Konfiguration als abgeschlossen betrachten. Wiederholen Sie den Aktionsaufruf, nachdem Sie den Header authorization entfernt haben. Der eigene Quickstart des Projekts ruft /v1 ganz ohne Bearer-Header auf. Eine Installation ohne konfigurierte Laufzeitauthentifizierung führt Aktionen daher für jeden aus, der den Port erreichen kann. Wenn der nicht authentifizierte Aufruf erfolgreich ist, haben Sie zwei Möglichkeiten: Konfigurieren Sie Laufzeittokens und bestätigen Sie, dass der anonyme Aufruf jetzt fehlschlägt. Oder beschränken Sie /api, /v1 und /mcp am Reverse Proxy auf die Adressen, von denen Ihre Agenten zugreifen. Nur /oauth/callback muss weltweit erreichbar bleiben, weil dies der einzige Pfad ist, den die Browser-Weiterleitung eines Providers benötigt.

Die Aktionsliste auf das reduzieren, was der Agent benötigt

Ein Gateway mit tausend dahinterliegenden Providern bietet einem Sprachmodell eine große Angriffsfläche. Zwei Steuerungen begrenzen sie.

OOMOL_CONNECT_ALLOWED_ACTIONS übernimmt eine durch Kommas getrennte Allowlist und unterstützt service.* sowie *. OOMOL_CONNECT_BLOCKED_ACTIONS ist die Denylist und hat Vorrang. Wenn Sie die Allowlist auf github.get_current_user,github.list_issues setzen, wird jede andere Aktion unabhängig von der Anfrage des Agents abgelehnt. Das ist der Unterschied zwischen einem Fehler und einem Sicherheitsvorfall. Laufzeit-Tokens haben zusätzlich zu den globalen Regeln eigene Aktionsregeln. Ihre allowedProxies-Liste ist zunächst leer, daher wird POST /v1/proxy/:service abgelehnt, bis Sie die Aktion ausdrücklich freigeben. Dieser Proxy-Endpunkt leitet eine unveränderte Anfrage mit Ihren Zugangsdaten an einen Provider weiter. Lassen Sie die Liste daher leer, sofern sie nicht von einem bestimmten Agenten benötigt wird.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK ist standardmäßig auf false gesetzt. Dadurch wird verhindert, dass eine Verbindung zu einem selbst gehosteten Provider auf eine private Adresse wie den Cloud-Metadatendienst unter 169.254.169.254 oder auf Ihre Datenbank im selben Netzwerk verweist. Lassen Sie diese Einstellung deaktiviert. Aktivieren Sie sie nur für einen Provider, den Sie selbst hosten.

Sichern Sie das System, das alle Tokens enthält

Zwei Dinge sind wichtig, und jedes ist ohne das andere nutzlos. Die Datenbank unter /app/data/connect.sqlite im Volume connector-data enthält die versiegelten Zugangsdaten. Der Verschlüsselungsschlüssel in .env entsiegelt sie. Ein Volume-Backup ohne den Schlüssel stellt nichts wieder her, und der Schlüssel ohne das Volume stellt ebenfalls nichts wieder her. Der Schlüssel gehört daher in Ihren Passwortmanager, und das Volume gehört in Ihre reguläre Backup-Rotation.

Stoppen Sie den Container, während Sie die SQLite-Datei kopieren. Eine Kopie, die während eines Schreibvorgangs erstellt wird, kann als beschädigte Datenbank wiederhergestellt werden.

docker volume ls | grep connector-data
docker compose stop connector
docker run --rm -v open-connector_connector-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/connector-data.tgz -C /data .
docker compose start connector

Der Volume-Name besteht aus Ihrem Projektverzeichnis plus _connector-data. Deshalb steht der erste Befehl hier: Fügen Sie den tatsächlichen Namen in den dritten Befehl ein. Übertragen Sie das Archiv mit restic-Backups von einem VPS vom VPS weg. Das Archiv wird vor der Übertragung verschlüsselt, weil es den Zugangsdatenbestand enthält.

Die Laufzeitumgebung speichert standardmäßig die letzten 5,000 Aktionsausführungen als Audit-Datensätze. Dadurch kann die Konsole anzeigen, welcher Agent was und wann ausgeführt hat. Dieses Protokoll sollten Sie zuerst lesen, wenn sich ein Agent ungewöhnlich verhält. Richten Sie außerdem eine Uptime-Kuma-Statusseite für https://connect.example.com/health ein. Wenn das Gateway nicht mehr antwortet, schlagen Agenten auf schwer nachvollziehbare Weise fehl. Die Kenntnis, dass das Gateway ausgefallen ist, erspart Ihnen eine Stunde beim Lesen der Agentenausgabe.

Was fehlschlägt und welche Meldung Sie sehen

redirect_uri_mismatch beim Anbieter. Der Ursprung und die registrierte Callback-URL stimmen nicht überein. Vergleichen Sie die exakte Zeichenfolge aus /api/oauth/configs mit den App-Einstellungen des Anbieters. Prüfen Sie dabei auch https mit http sowie einen möglichen abschließenden Schrägstrich.

Jeder /api-Aufruf gibt 401 zurück. Der Header mit dem Admin-Token fehlt oder ist falsch geschrieben. Der Header lautet Authorization: Bearer <token>. Die Webkonsole fordert dasselbe Token an.

Der Container läuft, und die Zugangsdaten liegen im Klartext vor. Das passiert, wenn OOMOL_CONNECT_ENCRYPTION_KEY den Container nicht erreicht, weil die Laufzeitumgebung die Zugangsdaten unverschlüsselt speichert, statt den Start zu verweigern. Überprüfen Sie dies in Ihrer eigenen Installation: Verbinden Sie einen Anbieter mit einem API-Schlüssel, den Sie erkennen können, und suchen Sie anschließend in der Datenbank danach.

docker compose cp connector:/app/data/connect.sqlite /tmp/connect.sqlite
grep -c 'github_pat_' /tmp/connect.sqlite
shred -u /tmp/connect.sqlite

Ein Wert größer als 0 bedeutet, dass der Schlüssel nicht wirksam ist. Prüfen Sie daher, ob .env im selben Verzeichnis wie compose.yaml liegt und ob docker compose config den Wert anzeigt. Wenn der Schlüssel gesetzt ist, gibt dieselbe Suche 0 zurück, weil der Datensatz mit AES-256-GCM (Advanced Encryption Standard, 256-Bit-Schlüssel, Galois/Counter-Modus) verschlüsselt ist.

Nach einer Wiederherstellung lässt sich nichts entschlüsseln. Der Verschlüsselungsschlüssel wurde geändert oder ging verloren. Er wird absichtlich niemals neben den Daten gespeichert. Daher gibt es keinen Wiederherstellungspfad und kein Support-Ticket, das dieses Problem behebt. Verbinden Sie jeden Anbieter erneut. Eine Schlüsselrotation wird über eine separate Schlüsselvariable und einen Datenbefehl in der Laufzeitumgebung unterstützt. Lesen Sie daher vor einer Rotation die aktuellen Release Notes.

Der Agent meldet einen Fehler für eine Aktion, die im Katalog sichtbar ist. Erkennung und Ausführung sind getrennt. Eine Aktion kann in search_actions erscheinen und dennoch von OOMOL_CONNECT_ALLOWED_ACTIONS, der Denylist oder den eigenen Regeln des betreffenden Laufzeittokens abgelehnt werden.

Upgrades. Sichern Sie das Volume, ändern Sie den Image-Tag auf das neue Release und führen Sie anschließend docker compose pull && docker compose up -d aus. Überwachen Sie docker compose logs -n 50 connector auf eine Migrationsmeldung. Führen Sie danach den Health Check und eine echte Aktion erneut aus, bevor Sie dem System wieder vertrauen. Für ein Rollback setzen Sie den alten Tag wieder ein. Das funktioniert nur, weil Sie ihn fest angegeben haben.

FAQ

Benötige ich eine öffentliche Domain, um Open Connector selbst zu hosten?

Für Anbieter, die einen API-Schlüssel verwenden, nein: Ein Gateway auf 127.0.0.1 ist ausreichend. Für OAuth ist sie in der Praxis erforderlich. Der Anbieter leitet einen Browser an Ihre Callback-URL weiter. Diese URL muss daher aus dem öffentlichen Internet erreichbar sein. Anbieter lehnen reines http:// außerhalb von localhost ab. Setzen Sie OOMOL_CONNECT_ORIGIN vor dem ersten Start auf Ihren https://-Hostnamen und registrieren Sie <origin>/oauth/callback in der OAuth-Anwendung des Anbieters.

Was passiert, wenn ich den Verschlüsselungsschlüssel von Open Connector verliere?

Die gespeicherten Zugangsdaten können nicht entschlüsselt werden. Eine Wiederherstellung ist nicht möglich. Der Schlüssel wird absichtlich niemals zusammen mit den Daten gespeichert. Niemand, der Zugriff auf die Datenbank hat, kann die Daten daher lesen, auch Sie nicht. Ihre einzige Möglichkeit besteht darin, einen neuen Schlüssel zu setzen und jeden Anbieter erneut zu verbinden. Bewahren Sie den Schlüssel in einem Passwortmanager und die Datenbank in Ihrer Backup-Rotation auf, da eine Wiederherstellung beides benötigt.

Kann mein AI-Agent das Zugriffstoken des Anbieters sehen?

Nicht, wenn er den Gateway verwendet. Der Agent authentifiziert sich mit einem Laufzeittoken, das mit oct_ beginnt. Der Gateway fügt das Anbieterkonto im Server in die ausgehende Anfrage ein und gibt nur die Antwort zurück. Zwei Dinge heben diese Eigenschaft auf: der /v1/proxy/:service-Endpunkt, der unveränderte Anfragen mit angehängtem Zugangsschlüssel weiterleitet und dessen Berechtigungen aus gutem Grund zunächst leer sind, sowie das Einfügen eines API-Schlüssels in den Agenten durch Sie selbst. Dadurch wird der Gateway vollständig umgangen.

Sollte der Gateway aus dem öffentlichen Internet erreichbar sein?

Nur /oauth/callback muss erreichbar sein. Veröffentlichen Sie den Container-Port auf 127.0.0.1, damit Docker-NAT-Regeln ihn nicht an Ihrer Firewall vorbei erreichbar machen können, und schalten Sie den Reverse Proxy davor. Testen Sie anschließend einen Aktionsaufruf ohne authorization-Header. Wenn er erfolgreich ist, beschränken Sie /api, /v1 und /mcp am Proxy auf die Adressen, die Ihre Agenten verwenden, bis nur noch authentifizierte Aufrufe funktionieren.

Ist Open Connector für den produktiven Einsatz geeignet?

Open Connector steht unter der Apache-2.0-Lizenz und wird schnell weiterentwickelt: Das Repository wurde am 29. Juni 2026 veröffentlicht und v1.3.3 am 30. Juli 2026 freigegeben. Betrachten Sie daher jede Versionsnummer in diesem Leitfaden als Stand vom 1. August 2026. Führen Sie Open Connector mit einem festgelegten Release-Tag aus, niemals mit latest oder tip. Lesen Sie vor jedem Upgrade die Release Notes und halten Sie ein Volume-Backup vor, das Sie bereits einmal wiederhergestellt haben. Das Design ist für einen Server in Ihrem Besitz solide. Das Risiko liegt in den häufigen Versionsänderungen, nicht in der Architektur.