Open Connector für AI-Agenten selbst hosten

Was Open Connector für einen AI-Agenten leistet

Das Self-Hosting von Open Connector setzt ein gemeinsames Authentifizierungs-Gateway zwischen Ihre AI-Agenten und jede von ihnen aufgerufene Software-as-a-Service-API (SaaS). Der Agent verwaltet dadurch niemals ein Provider-Token. Open Connector ist ein Source-Available-Gateway von OOMOL Lab. Derzeit gilt eine geänderte Apache-2.0-Lizenz mit zusätzlichen Bedingungen. Releases bis einschließlich v1.9.4 bleiben unter Apache 2.0. Mit v1.9.5 wurde die Änderung eingeführt. Wenn Sie einen gehosteten oder verwalteten Dienst anbieten, dessen Hauptwert in der Funktionalität von OpenConnector liegt, benötigen Sie eine kommerzielle Lizenz von OOMOL. Open Connector 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 einen eigenen OAuth-Flow (Open Authorization), 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 Credential-Speicher und fünf Refresh-Schleifen, die jeweils vor Ablauf eines Tokens ausgeführt werden müssen. Diese Logik schreibt fast niemand selbst. Stattdessen erstellen Betreiber pro Dienst ein langlebiges persönliches Access-Token und hinterlegen es in der Agent-Konfiguration, einer Umgebungsdatei oder sogar direkt im Prompt. Jedes Tool, das der Agent ausführt, kann dieses Token lesen. Außerdem gelangt es in das Transkript. Genau dieses Problem beschreibt wie Sie Geheimnisse aus AI-Agenten heraushalten.

Ein Authentifizierungs-Gateway teilt das Credential in zwei Teile. Das Gateway speichert das Provider-Credential und führt den OAuth-Flow aus. Der Agent erhält ein Runtime-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 Response-Body zurück. Der Agent erhält das Provider-Access-Token nie. Wenn ein Agent-Transkript offengelegt wird, müssen Sie daher nur ein widerrufbares Runtime-Token ersetzen und nicht Ihr GitHub-Konto absichern.

Der Katalog nennt mehr als 1,000 Provider und 10,000 vorgefertigte Aktionen. Diese Zahlen stammen vom Projekt selbst und lassen sich nicht von außen verifizieren. Verifizieren lässt sich jedoch die Struktur: ein HTTP-Endpunkt pro Aktion, eine gespeicherte Verbindung pro Provider und ein Token pro Agent. Wenn die Agent-Seite für Sie noch neu ist und sich Begriffe wie Tool-Aufruf oder MCP-Server noch nicht gefestigt haben, baut der schrittweise Pfad in wie Sie AI-Agenten von Grund auf lernen die Schleife, die Tools und die Sicherheitsgewohnheiten auf, die ein solches Gateway voraussetzt.

Warum Sie Open Connector selbst hosten sollten, 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 Schlüssel zu Ihren E-Mails und Repositorys. 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. Dieser VPS wird zum wertvollsten Server, den Sie betreiben. Er enthält in einer Datei gültige Zugangsdaten für ein Dutzend Dienste. Behandeln Sie ihn daher wie einen Host für einen Passwortmanager: Eine Firewall darf nur 443 öffnen, gemeinsame Logins sind nicht zulässig, und Sie müssen mindestens einmal eine Sicherung tatsächlich wiederhergestellt haben. Außerdem benötigen Sie eine Warnung, wenn der Server nicht mehr antwortet. Wenn Sie Ihren Passwort-Tresor nicht auf diesem System ablegen würden, sollten Sie dort auch den Connector nicht betreiben.

Vor der Installation eine Version festlegen

Open Connector ist noch jung. Diese Anleitung verwendet v1.3.3, veröffentlicht am 30. Juli 2026, als festgelegten Installationsstand vom 1. August 2026. Diese Version ist nicht mehr die neueste Veröffentlichung. Die Registry veröffentlicht außerdem ein tip-Tag, das aus dem neuesten Commit auf main erstellt wird.

Bei einem so neuen Projekt ändern sich bewegliche Tags häufig. Ein docker compose pull, das zwei Releases überspringt, kann einen Endpunkt ändern, von dem Ihr Agent abhängt. Dann verbringen Sie den Abend damit, das Problem fälschlicherweise beim Agenten zu suchen. Fixieren Sie das Image auf ein Release-Tag. Aktualisieren Sie es erst, wenn Sie dies selbst entscheiden, und lesen Sie vorher die Release Notes.

Open Connector mit TLS auf Ihrem eigenen VPS bereitstellen

Vor dem Start des Containers benötigen Sie:

• Docker Engine 28.0.0 oder neuer 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 Sie weiter unten generieren

Der Reverse Proxy Traefik für mehrere Docker-Compose-Anwendungen behandelt die Proxy-Seite. Die vollständige Einrichtung der Zertifikatsverwaltung 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 von beiden gibt es einen Standardwert. Die Laufzeit startet jedoch auch ohne diese Werte problemlos.

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 steht weiter unten in der Fehlerliste.

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 der festgelegte Tag anstelle von latest. Die zweite Änderung betrifft den Port. Die Upstream-Datei veröffentlicht 3000:3000. Dadurch wird der Port an jedes Host-Interface 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. Dieses Problem wird unter warum Docker-Ports ufw umgehen beschrieben. Mit 127.0.0.1:3000:3000 wird der Port nur auf dem Loopback-Interface veröffentlicht. Ihr Reverse Proxy verbindet sich vom selben Host. Vor Docker Engine 28.0.0 konnten Hosts im selben L2-Segment Ports erreichen, die auf localhost veröffentlicht waren. Deshalb erfordert dieser Leitfaden Version 28.0.0 oder neuer.

:? kennzeichnet jede Variable als erforderlich. Der Stack verweigert dadurch 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. Halten Sie /v1 und /mcp am Reverse Proxy geheim, bis Sie das erste Runtime-Token weiter unten erstellt haben.

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 der Listener an jedes IPv4-Interface gebunden ist. Das beweist jedoch nicht, dass der Dienst aus dem Internet erreichbar ist: Upstream-Firewalls oder Regeln in Dockers DOCKER-USER-Chain können externen Datenverkehr weiterhin blockieren. Eine verweigerte Verbindung beim Health Check bedeutet, dass der Container noch nicht lauscht. 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-Callbacks den richtigen Origin benötigen

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 wirkt. Die Laufzeitumgebung erstellt daraus die Redirect-URI im Format <origin>/oauth/callback. Wenn der Wert nicht gesetzt ist, wird als Origin standardmäßig http://localhost:3000 verwendet. Dadurch sendet die Laufzeitumgebung dem Provider eine Redirect-URI von http://localhost:3000/oauth/callback, während in Ihrer 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-Provider leitet den Browser an diese URI zurück. Die Adresse muss deshalb für diesen Browser erreichbar sein. OAuth erfordert nicht grundsätzlich einen öffentlichen Hostnamen. OpenConnector dokumentiert GitHub-Callbacks unter http://localhost:3000/oauth/callback. Diese VPS-Bereitstellung verwendet einen Hostnamen und ein Zertifikat, damit der Browser das Gateway über dessen HTTPS-Origin erreicht. Setzen Sie den Origin vor dem ersten Start, weil 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 zu übernehmen.

Verbinden Sie Ihren ersten Provider über OAuth

Erstellen Sie zuerst die OAuth-Anwendung 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 Auflistung zeigt die Redirect-URI, die die Laufzeitumgebung für jeden Provider erwartet. Damit können Sie am schnellsten prüfen, ob Ihr Origin übernommen wurde. Wenn dort weiterhin localhost steht, läuft der Container mit dem alten Wert. Der OAuth-Ablauf schlägt dann beim 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 liefert eine authorizationUrl zurück. Öffnen Sie sie in einem Browser und bestätigen Sie die Scopes. Der Provider leitet den Browser anschließend an /oauth/callback zurück. Dort tauscht die Laufzeitumgebung den Code aus und speichert die Anmeldedaten. Die Webkonsole an Ihrem Origin führt mit einem Formular durch dieselben Schritte und verwendet dabei 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 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 pro Agent ein Token aus und benennen Sie es nach diesem Agenten. Wenn Sie ein Token nicht identifizieren können, müssen Sie andernfalls alle Tokens widerrufen. Der Agent ruft die 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 hat. Die Provider-Payload befindet sich unter data. Das GitHub-Token ist an keiner Stelle dieser Antwort enthalten. Für einen MCP-Client verweisen Sie mit demselben Bearer-Header auf https://connect.example.com/mcp. Das Gateway stellt dann Discovery-Tools wie search_actions und execute_action bereit, nicht ein eigenes Tool pro API. Dadurch bleibt die Tool-Liste des Agenten klein. MCP-Server auf einer 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 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 nun fehlschlägt, oder beschränken Sie /api, /v1 und /mcp am Reverse Proxy auf die Adressen, von denen Ihre Agenten kommen. /oauth/callback muss für den Browser erreichbar sein, der die Autorisierung abschließt. Es muss nicht für das gesamte Internet geöffnet sein.

Die Aktionsliste auf das beschränken, was der Agent benötigt

Ein Gateway mit tausend dahinterliegenden Providern bietet einem Sprachmodell eine große Angriffsfläche. Sie wird noch größer, sobald das Modell Text liest, den es nicht selbst erstellt hat. Eine Seite, die von Ihrer eigenen SearXNG-Instanz als Antwort auf die Websuchen des Agents zurückgegeben wird, kann Anweisungen enthalten, die sich auf beliebige Aktionen beziehen, über die der Agent verfügt. Dieselbe Zurückhaltung, die einen Coding-Agent dazu bringt, die kleinste funktionierende Änderung vorzunehmen, sollte auch für seine Berechtigungen gelten: Gewähren Sie nur die wenigen Aktionen, die der Auftrag tatsächlich benötigt, und keine weiteren. Zwei Einstellungen schränken dies ein.

OOMOL_CONNECT_ALLOWED_ACTIONS akzeptiert eine durch Kommas getrennte Allowlist und unterstützt service.* sowie *. OOMOL_CONNECT_BLOCKED_ACTIONS ist die Denylist, und die Denylist 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-Token erhalten zusätzlich zu den globalen Regeln eigene Aktionsregeln. Ihre Liste allowedProxies ist zunächst leer, daher wird POST /v1/proxy/:service abgelehnt, bis Sie diese Aktion freigeben. Dieser Proxy-Endpunkt leitet eine unformatierte 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 wie den Cloud-Metadatendienst unter 169.254.169.254 oder auf Ihre Datenbank im selben Netzwerk zeigt. Lassen Sie diese Einstellung deaktiviert. Aktivieren Sie sie nur für einen Provider, den Sie selbst hosten.

Die Box sichern, die 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 unter .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 und _connector-data. Deshalb steht der erste Befehl dort: 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. Restic verschlüsselt es, bevor es den VPS verlässt, weil dieses Archiv den Zugangsdatenbestand enthält.

Die Laufzeitumgebung speichert die letzten Aktionsausführungen als Audit-Datensätze, standardmäßig 5,000. 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. Überwachen Sie außerdem https://connect.example.com/health mit einer Uptime-Kuma-Statusseite. Wenn das Gateway nicht mehr antwortet, schlagen Agenten auf schwer nachvollziehbare Weise fehl. Wenn bekannt ist, dass das Gateway nicht erreichbar ist, sparen Sie sich eine Stunde beim Lesen der Agentenausgabe.

Was fehlschlägt und welche Meldung Sie sehen

redirect_uri_mismatch beim Anbieter. Die Origin 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 gegenüber http sowie einen eventuell vorhandenen abschließenden Schrägstrich.

Jeder /api-Aufruf gibt 401 zurück. 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 geschieht, wenn OOMOL_CONNECT_ENCRYPTION_KEY den Container nie erreicht, weil die Laufzeitumgebung die Zugangsdaten unverschlüsselt speichert, statt den Start zu verweigern. Belegen Sie dies in Ihrer eigenen Installation: Verbinden Sie einen Anbieter mit einem API-Key, 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, 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 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 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 trotzdem von OOMOL_CONNECT_ALLOWED_ACTIONS, der Denylist oder den eigenen Regeln des 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 den Tag fest angegeben haben.

FAQ

Benötige ich eine öffentliche Domain für das Self-Hosting von Open Connector?

Bei Providern, die einen API-Schlüssel verwenden, nein: Ein Gateway auf 127.0.0.1 reicht aus. Auch OAuth erfordert nicht grundsätzlich eine öffentliche Domain: OpenConnector dokumentiert den lokalen Callback von GitHub als http://localhost:3000/oauth/callback. Der Browser, der die Autorisierung abschließt, muss die Callback-URL erreichen können. Setzen Sie für diese VPS-Bereitstellung OOMOL_CONNECT_ORIGIN vor dem ersten Start auf Ihren https://-Hostnamen und registrieren Sie <origin>/oauth/callback in der OAuth-Anwendung des Providers.

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

Die gespeicherten Zugangsdaten können nicht entschlüsselt werden. Es gibt keine Wiederherstellungsmöglichkeit. Der Schlüssel wird absichtlich nie zusammen mit den Daten gespeichert. Daher kann niemand, der die Datenbank besitzt, sie auslesen, auch Sie nicht. Ihre einzige Möglichkeit besteht darin, einen neuen Schlüssel zu setzen und jeden Provider erneut zu verbinden. Bewahren Sie den Schlüssel in einem Passwort-Manager und die Datenbank in Ihrer Backup-Rotation auf, weil eine Wiederherstellung beides benötigt.

Kann mein AI-Agent das Access-Token des Providers sehen?

Nicht, wenn er den Aufruf über das Gateway ausführt. Der Agent authentifiziert sich mit einem Laufzeit-Token, das mit oct_ beginnt. Das Gateway fügt die Zugangsdaten des Providers auf dem Server in die ausgehende Anfrage ein und gibt nur die Antwort zurück. Zwei Dinge heben diese Eigenschaft auf: der Endpunkt /v1/proxy/:service, der unbearbeitete Anfragen mit angehängten 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, weil dadurch das Gateway vollständig umgangen wird.

Sollte das Gateway aus dem öffentlichen Internet erreichbar sein?

Der OAuth-Callback muss für den Browser erreichbar sein, der die Autorisierung abschließt. Ein Zugriff aus dem gesamten Internet ist dafür nicht erforderlich. Verwenden Sie mit Docker Engine 28.0.0 oder neuer und der standardmäßigen Bridge-Netzwerkverbindung 127.0.0.1 für den veröffentlichten Container-Port. Dadurch bleibt der veröffentlichte Port nur vom Host aus erreichbar. Schalten Sie den Reverse Proxy davor. Ältere Docker-Versionen erlaubten Hosts im selben L2-Segment, auf an localhost gebundene veröffentlichte Ports zuzugreifen. Testen Sie anschließend einen Aktionsaufruf ohne den Header authorization. Wenn er erfolgreich ist, beschränken Sie /api, /v1 und /mcp im Proxy auf die Adressen Ihrer Agenten, bis nur noch authentifizierte Aufrufe funktionieren.

Ist Open Connector für den produktiven Einsatz bereit?

Aktuelle Releases verwenden eine geänderte Apache-2.0-Lizenz mit zusätzlichen Bedingungen. Releases bis einschließlich v1.9.4, darunter das festgelegte v1.3.3, bleiben unter Apache 2.0. Ein gehosteter oder verwalteter Connector-Dienst, dessen Hauptwert in der Funktionalität von OpenConnector besteht, benötigt nach der aktuellen Lizenz eine kommerzielle Lizenz von OOMOL. Die Installationsbefehle für v1.3.3 sind weiterhin eine Momentaufnahme vom 1 August 2026. Dieses Release wurde am 30 Juli 2026 veröffentlicht. Führen Sie es mit einem festgelegten Release-Tag aus, niemals auf latest oder tip. Lesen Sie vor jedem Upgrade die Release-Hinweise und bewahren Sie ein Volume-Backup auf, das Sie bereits einmal wiederhergestellt haben. Das Design ist für einen eigenen Server solide. Das Risiko liegt in den häufigen Versionsänderungen, nicht in der Architektur.