Open Connector für AI-Agenten selbst hosten

Was Open Connector für einen AI-Agenten leistet

Wenn Sie Open Connector selbst hosten, befindet sich ein Authentifizierungs-Gateway zwischen Ihren AI-Agenten und jeder von ihnen aufgerufenen Software-as-a-Service-(SaaS-)API. Der Agent speichert 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 einzelner Container, speichert seinen Zustand in einer einzelnen SQLite-Datei und stellt Provider-Aktionen über HTTP und MCP (model context protocol) bereit.

Das Problem beginnt bei der zweiten Integration. Jeder Provider verwendet einen eigenen OAuth-(open authorization-)Ablauf, eine eigene Gültigkeitsdauer für Refresh-Tokens und eigene Bezeichnungen für Scopes. Fünf Provider manuell in einen Agenten zu integrieren bedeutet fünf Redirect-Handler, fünf Anmeldedatenspeicher und fünf Aktualisierungsschleifen, die vor dem Ablauf eines Tokens ausgeführt werden müssen. Fast niemand schreibt diesen Code. Stattdessen stellt man pro Dienst ein langlebiges persönliches Access-Token aus und fügt es in die Agentenkonfiguration, eine Umgebungsdatei oder sogar direkt in den Prompt ein. Danach kann jedes Tool, das der Agent ausführt, dieses Token lesen. Außerdem landet es im Transkript. Genau dieses Problem beschreibt Geheimnisse aus AI-Agenten heraushalten.

Ein Authentifizierungs-Gateway teilt die Anmeldedaten in zwei Teile. Das Gateway speichert die Provider-Anmeldedaten 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 die gespeicherten Anmeldedaten, fügt sie serverseitig in die ausgehende Anfrage ein und gibt nur den Antworttext zurück. Der Agent erhält das Provider-Access-Token niemals. Ein offengelegtes Agenten-Transkript kostet Sie daher nur ein widerrufbares Laufzeit-Token statt Ihres GitHub-Kontos.

Der Katalog nennt mehr als 1,000 Provider und 10,000 vorgefertigte Aktionen. Das ist eine 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 Sie Open Connector selbst hosten sollten, statt einen gehosteten Connector-Dienst zu verwenden

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

Machen Sie sich die Kosten bewusst, bevor Sie beginnen. Dieser VPS wird zum wertvollsten Server, den Sie betreiben. Er enthält in einer Datei aktive Zugangsdaten für ein Dutzend Dienste. Behandeln Sie ihn daher wie einen Host für einen Passwortmanager: Eine Firewall darf nur 443 freigeben, gemeinsame Logins sind nicht zulässig, und Sie müssen eine Sicherung mindestens einmal tatsächlich wiederhergestellt haben. Richten Sie außerdem einen Alarm ein, der auslöst, wenn der Server nicht mehr antwortet. Wenn Sie Ihren Passworttresor nicht auf diesem Rechner ablegen würden, sollten Sie auch den Connector nicht dort betreiben.

Fixieren Sie eine Version, bevor Sie etwas installieren

Open Connector ist noch jung. Das Repository wurde erstmals am 29. Juni 2026 veröffentlicht. Am 1. August 2026 ist v1.3.3 die neueste markierte Version. Sie wurde am 30. Juli 2026 veröffentlicht und trägt außerdem das latest-Tag. Die Registry veröffentlicht ebenfalls ein tip-Tag. Es basiert auf dem neuesten Commit in main.

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 beim Agent zu suchen. Fixieren Sie das Image auf ein Release-Tag. Aktualisieren Sie es erst, wenn Sie die Release Notes gelesen haben und sich dafür entscheiden.

Open Connector hinter TLS auf Ihrem eigenen VPS bereitstellen

Bevor der Container startet, benötigen Sie:

• Docker mit dem Compose-Plugin auf Ubuntu 24.04 oder einer vergleichbaren Distribution
• 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 beendet
• zwei zufällige Geheimnisse, die weiter unten erzeugt werden

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

Erzeugen Sie zuerst die Geheimnisse. Der Verschlüsselungsschlüssel schützt die gespeicherten Zugangsdaten. Das Admin-Token schützt die Webkonsole und die gesamte /api-Schnittstelle. Für keines der beiden Geheimnisse 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 Dienst zum ersten Mal starten. Für den Verschlüsselungsschlüssel gibt es keinen Wiederherstellungsweg. Der Grund dafür wird weiter unten in der Fehlerliste erklärt.

Erstellen Sie nun compose.yaml. Die 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 das festgelegte Tag anstelle von latest. Die zweite Änderung betrifft den Port. Die Upstream-Datei veröffentlicht 3000:3000. Dadurch wird der Port an jede Schnittstelle des Hosts gebunden. Docker schreibt veröffentlichte Ports in die NAT-Tabelle (Network Address Translation), bevor das ufw-Filter-Chain das Paket sieht. Daher schließt ufw deny 3000 diesen Port nicht. Dies 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 stellt die Verbindung vom selben Host her.

:? kennzeichnet jede Variable als erforderlich. Dadurch verweigert der Stack 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 beantwortet { "ok": true }, sobald die Laufzeit aktiv ist. ss muss 127.0.0.1:3000 ausgeben. Eine Zeile mit 0.0.0.0:3000 bedeutet, dass weiterhin das Upstream-Port-Mapping verwendet wird und das Gateway direkt aus dem gesamten Internet erreichbar ist. Wenn die Health-Prüfung die Verbindung ablehnt, lauscht der Container noch nicht. Sehen Sie daher die Logs ein, 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 erfordert

OOMOL_CONNECT_ORIGIN ist die Einstellung, die häufig übersprungen wird. Dadurch schlägt OAuth auf eine Weise fehl, die wie ein Fehler des Providers aussieht. 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. Dadurch sendet die Laufzeitumgebung dem Provider die Redirect-URI http://localhost:3000/oauth/callback, während in Ihrer OAuth-App 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-Provider leitet einen Browser zu dieser URI zurück. Deshalb muss sie unter einer von außen erreichbaren Adresse verfügbar sein. Provider lehnen reines http:// für alle Ziele außer localhost ab. Deshalb benötigt diese Bereitstellung einen Hostnamen und ein Zertifikat. Setzen Sie den Origin vor dem ersten Start. Der Wert wird beim Start eingelesen. Führen Sie nach dem Bearbeiten von .env oder compose.yaml erneut docker compose up -d aus, um die Änderung anzuwenden.

Ihren 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 /api-Aufruf enthält 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"

Diese Auflistung zeigt die Redirect-URI, die die Laufzeitumgebung für jeden Provider erwartet. Damit können Sie am schnellsten prüfen, ob Ihre Origin ü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-Anmeldedaten 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 Scopes. Der Provider leitet den Browser anschließend zurück an /oauth/callback. Dort tauscht die Laufzeitumgebung den Code aus und speichert die Anmeldedaten. Die Webkonsole unter Ihrer Origin führt mit einem Formular durch dieselben Schritte und verwendet dafür dasselbe Admin-Token. Provider, die einen einfachen API-Schlüssel verwenden, überspringen diesen gesamten Ablauf: PUT /api/connections/<service> mit {"authType":"api_key","values":{"apiKey":"..."}} speichert den Schlüssel direkt.

Geben Sie jedem Agenten ein Laufzeittoken, niemals die Zugangsdaten

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 pro Agent ein Token aus und benennen Sie es nach diesem Agenten. Wenn Sie ein Token nicht identifizieren können, müssen Sie sonst alle Tokens widerrufen. Der Agent ruft Aktionen anschließend über normales 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 hat. Die Provider-Nutzdaten befinden sich unter data. Das GitHub-Token ist an keiner Stelle in dieser Antwort enthalten. Für einen MCP-Client verweisen Sie ihn mit demselben Bearer-Header auf https://connect.example.com/mcp. Das Gateway stellt dann Discovery-Tools wie search_actions und execute_action bereit, statt ein Tool pro API anzubieten. Dadurch bleibt die Tool-Liste des Agenten klein. MCP-Server auf einem VPS ausführen behandelt die Client-Seite dieser Konfiguration.

Führen Sie eine weitere Prüfung durch, bevor Sie die Einrichtung als abgeschlossen betrachten. Wiederholen Sie den Aktionsaufruf, nachdem Sie den Header authorization gelöscht haben. Der Quickstart des Projekts ruft /v1 ganz ohne Bearer auf. Eine Installation ohne konfigurierte Laufzeitauthentifizierung führt daher Aktionen für jeden aus, der den Port erreichen kann. Wenn Ihr nicht authentifizierter 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 Verbindungen herstellen. Nur /oauth/callback muss für die Welt offen bleiben, weil dies der einzige Pfad ist, den die Browser-Weiterleitung eines Providers benötigt.

Reduzieren Sie die Aktionsliste auf das, was der Agent benötigt

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

OOMOL_CONNECT_ALLOWED_ACTIONS akzeptiert 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 abgelehnt, unabhängig davon, was der Agent anfordert. 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 anfangs leer. Daher wird POST /v1/proxy/:service abgelehnt, bis Sie es freigeben. Dieser Proxy-Endpunkt leitet eine unveränderte Anfrage mit Ihren Zugangsdaten an einen Provider weiter. Lassen Sie ihn daher leer, sofern ihn nicht ein bestimmter Agent benötigt.

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 zeigt, beispielsweise auf den Cloud-Metadatendienst unter 169.254.169.254 oder auf Ihre Datenbank im selben Netzwerk. Lassen Sie diese Einstellung deaktiviert. Aktivieren Sie sie nur für einen Provider, den Sie selbst hosten.

Sichern Sie das System, das jedes Token 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 Backup des Volumes ohne den Schlüssel stellt nichts wieder her. Der Schlüssel ohne das Volume stellt ebenfalls nichts wieder her. Der Schlüssel gehört daher in Ihren Passwortmanager. 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 Name des Volumes besteht aus Ihrem Projektverzeichnis plus _connector-data. Deshalb steht der erste Befehl dort: Fügen Sie den tatsächlichen Namen in den dritten Befehl ein. Senden Sie das Archiv mit restic-Backups von einem VPS vom VPS weg. restic verschlüsselt es, bevor es den VPS verlässt, weil dieses Archiv den Speicher für die Zugangsdaten 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 auf https://connect.example.com/health. Wenn das Gateway nicht mehr antwortet, schlagen Agenten auf verwirrende Weise fehl. Wenn Sie wissen, dass das Gateway nicht verfügbar ist, sparen Sie 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 unterscheiden sich. Vergleichen Sie die exakte Zeichenfolge aus /api/oauth/configs mit den App-Einstellungen des Anbieters. Prüfen Sie dabei auch https gegen http sowie einen möglichen abschließenden Schrägstrich.

Jeder Aufruf von /api liefert 401. Der Header für das 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. Die Laufzeitumgebung speichert die Zugangsdaten dann unverschlüsselt, statt den Start zu verweigern. Belegen Sie das 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 über 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, liefert dieselbe Suche 0. Der Datensatz ist dann mit AES-256-GCM verschlüsselt (Advanced Encryption Standard, 256-Bit-Schlüssel, Galois/Counter-Modus).

Nach einer Wiederherstellung kann nichts entschlüsselt werden. Der Verschlüsselungsschlüssel wurde geändert oder ging verloren. Er wird absichtlich niemals neben den Daten gespeichert. Daher gibt es keinen Wiederherstellungspfad und auch kein Support-Ticket, das weiterhilft. 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 jeder Rotation die Versionshinweise der aktuellen Version.

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 angezeigt werden und dennoch von OOMOL_CONNECT_ALLOWED_ACTIONS, der Denylist oder den eigenen Regeln dieses Laufzeittokens abgelehnt werden.

Upgrades. Sichern Sie das Volume, ändern Sie den Image-Tag auf die neue Version 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 Healthcheck und eine echte Aktion erneut aus, bevor Sie dem System wieder vertrauen. Für ein Rollback setzen Sie den alten Tag zurück. Das funktioniert nur, weil Sie ihn fest zugeordnet 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. Daher muss diese URL aus dem öffentlichen Internet erreichbar sein. Anbieter akzeptieren außerhalb von localhost keine einfache http://. Setzen Sie OOMOL_CONNECT_ORIGIN vor dem ersten Start auf Ihren https://-Hostnamen und registrieren Sie <origin>/oauth/callback in der OAuth-App 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 nie zusammen mit den Daten gespeichert. Daher kann niemand, der über die Datenbank verfügt, die Daten lesen. Das gilt auch für Sie. Ihre einzige Möglichkeit besteht darin, einen neuen Schlüssel festzulegen und jeden Anbieter erneut zu verbinden. Bewahren Sie den Schlüssel in einem Passwortmanager und die Datenbank in Ihrer Backup-Rotation auf. Eine Wiederherstellung benötigt beides.

Kann mein KI-Agent das Zugriffstoken des Anbieters sehen?

Nicht, wenn er über das Gateway aufruft. Der Agent authentifiziert sich mit einem Laufzeittoken, das mit oct_ beginnt. Das Gateway fügt die Zugangsdaten des Anbieters auf dem 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 unbearbeitete Anfragen mit Ihren angefügten Zugangsdaten 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 das Gateway vollständig umgangen.

Sollte das 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 die NAT-Regeln von Docker ihn nicht an Ihrer Firewall vorbei freigeben 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 im Proxy auf die Adressen, die Ihre Agenten verwenden, bis nur noch authentifizierte Aufrufe funktionieren.

Ist Open Connector für den produktiven Einsatz bereit?

Das Projekt steht unter der Apache-2.0-Lizenz und entwickelt sich schnell weiter: Das Repository wurde am 29. Juni 2026 veröffentlicht, und v1.3.3 wurde am 30. Juli 2026 veröffentlicht. Betrachten Sie daher jede Versionsnummer in diesem Leitfaden als Stand vom 1. August 2026. Führen Sie es mit einem festgelegten Release-Tag aus, niemals mit latest oder tip. Lesen Sie vor jedem Upgrade die Release-Hinweise und halten Sie eine Volume-Sicherung vor, die Sie bereits einmal wiederhergestellt haben. Das Design ist für einen von Ihnen verwalteten Server solide. Das Risiko liegt in den häufigen Versionsänderungen, nicht in der Architektur.