Jak samodzielnie hostować Open Connector dla agentów AI

Rola Open Connector w pracy agenta AI

Samodzielne hostowanie Open Connector pozwala umieścić jedną bramę uwierzytelniania między agentami AI a wszystkimi interfejsami API typu SaaS, z których korzystają. Dzięki temu agent nigdy nie przechowuje tokenów dostawcy. Jest to otwartoźródłowa brama od OOMOL Lab, udostępniona na licencji Apache 2.0. Działa jako pojedynczy kontener, przechowuje stan w jednym pliku SQLite i udostępnia akcje dostawców poprzez HTTP oraz MCP (model context protocol).

Problemy zaczynają się przy drugiej integracji. Każdy dostawca posiada własny proces OAuth (open authorization), własny czas życia tokena odświeżania oraz własne nazwy zakresów uprawnień (scope). Ręczne integrowanie pięciu dostawców z agentem oznacza konieczność obsługi pięciu przekierowań, pięciu magazynów poświadczeń oraz pięciu pętli odświeżania, które muszą zostać wykonane przed wygaśnięciem tokena. Prawie nikt nie pisze takiego kodu samodzielnie. Zamiast tego generuje się jeden długożyjący osobisty token dostępu (personal access token) dla każdej usługi i wkleja go do konfiguracji agenta, pliku środowiskowego lub bezpośrednio do promptu. Taki token jest następnie dostępny dla każdego narzędzia uruchamianego przez agenta i trafia do transkrypcji, co prowadzi do naruszeń bezpieczeństwa opisanych w utrzymywanie sekretów poza zasięgiem agentów AI.

Brama uwierzytelniania dzieli poświadczenia na dwie części. Brama przechowuje poświadczenia dostawcy i obsługuje proces OAuth. Agent otrzymuje token wykonawczy, który jest ważny wyłącznie w relacji z bramą. Gdy agent wywołuje akcję, brama ładuje zapisane poświadczenia, wstrzykuje je do wychodzącego żądania po stronie serwera i zwraca jedynie treść odpowiedzi. Agent nigdy nie otrzymuje tokena dostępu dostawcy, więc wyciek transkrypcji agenta skutkuje utratą jedynie unieważnialnego tokena wykonawczego, a nie dostępem do całego konta GitHub.

Katalog reklamuje ponad 1000 dostawców i 10 000 gotowych akcji; są to dane własne projektu, których nie można zweryfikować z zewnątrz. Można natomiast zweryfikować architekturę: jeden punkt końcowy HTTP na akcję, jedno zapisane połączenie na dostawcę, jeden token na agenta. Jeśli strona kliencka agenta jest wciąż nowością, a terminy takie jak wywołanie narzędzia (tool call) czy serwer MCP nie zostały jeszcze w pełni ustandaryzowane, ścieżka szkoleniowa w jak uczyć się agentów AI od podstaw pozwala zbudować pętlę, narzędzia oraz nawyki bezpieczeństwa, które brama tego typu uznaje za już wdrożone.

Dlaczego warto hostować Open Connector samodzielnie zamiast korzystać z zewnętrznej usługi

Zewnętrzna usługa typu connector wykonuje tę samą pracę, przechowując tokeny odświeżania dla każdego podłączonego dostawcy. Token odświeżania dla Google lub GitHub to długoterminowy klucz dostępu do poczty i repozytoriów, który zazwyczaj pozostaje ważny nawet po zmianie hasła. Naruszenie bezpieczeństwa dostawcy staje się Twoim naruszeniem. Samodzielny hosting przenosi te dane do bazy SQLite na maszynie, którą wynajmujesz i administrujesz, zabezpieczonej kluczem, który nigdy nie opuszcza Twojego serwera.

Przed rozpoczęciem oceń koszty. Ten VPS stanie się najważniejszym serwerem w Twojej infrastrukturze. Przechowuje on w jednym pliku aktywne poświadczenia do kilkunastu usług, dlatego wymaga traktowania na równi z serwerem menedżera haseł: firewalla otwierającego wyłącznie port 443, braku współdzielonych kont, kopii zapasowej, którą faktycznie przetestowano poprzez przywrócenie, oraz powiadomień o braku odpowiedzi serwera. Jeśli nie umieściłbyś na tej maszynie swojego sejfu z hasłami, nie instaluj na niej również connectora.

Przypnij wersję przed instalacją

Open Connector jest młodym projektem. Repozytorium pojawiło się 29 czerwca 2026 roku, a na dzień 1 sierpnia 2026 roku najnowszym otagowanym wydaniem jest v1.3.3, opublikowane 30 lipca 2026 roku i oznaczone również tagiem latest. Rejestr publikuje także tag tip, budowany z najnowszego commita w gałęzi main.

W tak nowym projekcie zmienne tagi są często aktualizowane. Tag docker compose pull, który przeskakuje dwa wydania, może zmienić punkt końcowy (endpoint), od którego zależy agent, co wymusi poświęcenie wieczoru na debugowanie problemu z agentem. Przypnij obraz do tagu wydania i aktualizuj go w wybranym przez siebie momencie, po uprzednim zapoznaniu się z informacjami o wydaniu (release notes).

Wdrożenie Open Connector za TLS na własnym VPS

Przed uruchomieniem kontenera wymagane są:

• Docker z wtyczką Compose na systemie Ubuntu 24.04 lub zbliżonym
• nazwa hosta, której rekord A wskazuje na ten VPS, na przykład connect.example.com
• reverse proxy, które obsługuje terminację TLS (transport layer security) dla tej nazwy hosta
• dwa losowe sekrety, wygenerowane poniżej

Artykuł Traefik reverse proxy dla wielu aplikacji Docker Compose opisuje konfigurację proxy. Analogiczny proces obsługi certyfikatów od początku do końca dla pojedynczej aplikacji znajduje się w przewodniku n8n na VPS z Docker i HTTPS.

Najpierw wygeneruj sekrety. Klucz szyfrujący zabezpiecza przechowywane poświadczenia. Token administratora chroni konsolę webową oraz całą powierzchnię /api. Żaden z nich nie posiada wartości domyślnej, a środowisko uruchomieniowe wystartuje bez nich, co jest niepożądane.

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

Skopiuj obie wartości do menedżera haseł przed pierwszym uruchomieniem. Klucz szyfrujący nie posiada ścieżki odzyskiwania, a powód tego stanu rzeczy znajduje się na liście awarii poniżej.

Teraz compose.yaml. Różni się on od przykładu upstream w dwóch miejscach i oba są istotne.

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:

Pierwsza zmiana to przypięta wersja (tag) zamiast latest. Druga to port. Plik upstream publikuje 3000:3000, co wiąże usługę z każdym interfejsem na hoście. Docker zapisuje opublikowane porty w tablicy NAT (network address translation), zanim łańcuch filtrów ufw zobaczy pakiet, więc ufw deny 3000 nie zamyka tego portu – jest to pułapka opisana w dlaczego porty Dockera omijają ufw. Zapis 127.0.0.1:3000:3000 publikuje usługę tylko na interfejsie loopback, a Twoje reverse proxy łączy się z tego samego hosta.

:? oznacza każdą zmienną jako wymaganą, więc stos odmawia uruchomienia, gdy brakuje .env, zamiast startować z niezaszyfrowanymi poświadczeniami. Przechowywanie wartości w .env zamiast w pliku compose to wzorzec opisany w pliki env i sekrety w Docker Compose.

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 odpowiada { "ok": true }, gdy środowisko uruchomieniowe jest gotowe. ss musi zwrócić 127.0.0.1:3000. Linia zawierająca 0.0.0.0:3000 oznacza, że mapowanie portów jest nadal w wersji upstream, a brama odpowiada bezpośrednio całemu internetowi. Błąd "Connection refused" podczas sprawdzania stanu (health check) oznacza, że kontener jeszcze nie nasłuchuje, więc sprawdź logi przed ingerencją w proxy.

    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"

Dlaczego OAuth wymaga posiadania rzeczywistej nazwy hosta

OOMOL_CONNECT_ORIGIN to ustawienie, które jest często pomijane, a jego brak powoduje błędy OAuth, które wyglądają jak usterki po stronie dostawcy. Środowisko uruchomieniowe buduje swój URI przekierowania na podstawie tego źródła, w formacie <origin>/oauth/callback. Jeśli pozostanie nieustawione, źródło domyślnie przyjmuje wartość http://localhost:3000, więc środowisko wysyła do dostawcy URI przekierowania http://localhost:3000/oauth/callback, podczas gdy aplikacja OAuth ma zarejestrowane https://connect.example.com/oauth/callback. Te dwa ciągi znaków różnią się, dlatego GitHub zwraca błąd:

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

Dostawca OAuth przekierowuje przeglądarkę z powrotem na ten URI, co oznacza, że musi to być adres dostępny z zewnątrz, a dostawcy odrzucają zwykłe http:// dla wszystkiego poza localhost. To jedyny powód, dla którego to wdrożenie wymaga nazwy hosta i certyfikatu. Ustaw źródło przed pierwszym uruchomieniem, ponieważ wartość ta jest odczytywana podczas startu: po edycji .env lub compose.yaml, uruchom ponownie docker compose up -d, aby zastosować zmiany.

Podłączanie pierwszego dostawcy przez OAuth

Najpierw utwórz aplikację OAuth u dostawcy. W serwisie GitHub ścieżka prowadzi przez Settings, następnie Developer settings, potem OAuth Apps i New OAuth App. Ustaw adres URL wywołania zwrotnego autoryzacji na https://connect.example.com/oauth/callback. Zachowaj identyfikator klienta (client ID) oraz klucz tajny klienta (client secret).

Każde wywołanie /api przenosi token administratora, dlatego wyeksportuj go jednorazowo dla bieżącej sesji powłoki.

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

To zestawienie pokazuje identyfikator URI przekierowania, którego środowisko uruchomieniowe oczekuje dla każdego dostawcy. Jest to najszybszy sposób sprawdzenia, czy zmiana źródła (origin) weszła w życie. Jeśli nadal widnieje tam localhost, kontener działa ze starą wartością, a proces OAuth zakończy się niepowodzeniem w ostatnim kroku.

Zapisz poświadczenia klienta, a następnie rozpocznij autoryzację.

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"}'

Drugie wywołanie zwraca authorizationUrl. Otwórz ten adres w przeglądarce, zatwierdź zakresy (scopes), a dostawca przekieruje przeglądarkę z powrotem do /oauth/callback, gdzie środowisko uruchomieniowe wymieni kod i zapisze poświadczenia. Konsola internetowa w Twoim źródle przeprowadza te same kroki za pomocą formularza, korzystając z tego samego tokena administratora. Dostawcy używający zwykłego klucza API pomijają cały ten proces: PUT /api/connections/<service> wraz z {"authType":"api_key","values":{"apiKey":"..."}} zapisuje klucz bezpośrednio.

Nadaj każdemu agentowi token wykonawczy, nigdy dane uwierzytelniające

Agent uwierzytelnia się w bramie za pomocą tokena wykonawczego, który jest generowany przez API administratora.

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"}'

Odpowiedź zawiera token rozpoczynający się od oct_. Należy wydać jeden token na agenta i nazwać go zgodnie z nazwą tego agenta, ponieważ cofnięcie uprawnień dla tokena, którego nie można zidentyfikować, oznacza konieczność unieważnienia wszystkich tokenów. Następnie agent wywołuje akcje za pośrednictwem standardowego protokołu HTTP.

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":{}}'

Poprawna odpowiedź to koperta, której pole success ma wartość true, a ładunek dostawcy znajduje się w data. Token GitHub nie znajduje się w tej odpowiedzi. W przypadku klienta MCP należy wskazać adres https://connect.example.com/mcp z tym samym nagłówkiem bearer, a brama udostępni narzędzia do wykrywania, takie jak search_actions i execute_action, zamiast jednego narzędzia na API, co pozwala zachować krótką listę narzędzi agenta. Uruchamianie serwerów MCP na VPS opisuje tę część konfiguracji po stronie klienta.

Przed zakończeniem prac należy wykonać jeszcze jedną kontrolę. Należy powtórzyć wywołanie akcji z usuniętym nagłówkiem authorization. Szybki start projektu wywołuje /v1 bez żadnego tokena bearer, więc instalacja bez skonfigurowanego uwierzytelniania wykonawczego wykona akcje dla każdego, kto ma dostęp do portu. Jeśli nieuwierzytelnione wywołanie zakończy się powodzeniem, istnieją dwa rozwiązania: skonfigurować tokeny wykonawcze i potwierdzić, że wywołanie anonimowe teraz kończy się błędem, lub ograniczyć dostęp do /api, /v1 i /mcp na reverse proxy tylko do adresów, z których pochodzą agenci. Tylko /oauth/callback musi pozostać otwarte dla świata, ponieważ jest to jedyna ścieżka wymagana przez przekierowanie przeglądarki dostawcy.

Ograniczenie listy działań do niezbędnego minimum

Brama z tysiącem dostawców w tle stanowi rozległą powierzchnię ataku dla modelu językowego. Powierzchnia ta powiększa się, gdy model zaczyna przetwarzać tekst, którego sam nie wygenerował, ponieważ strona zwrócona przez własną instancję SearXNG odpowiadającą na zapytania agenta może zawierać instrukcje wymierzone w działania, do których agent ma uprawnienia. Ta sama powściągliwość, która sprawia, że agent programistyczny wprowadza najmniejszą działającą zmianę, powinna dotyczyć jego uprawnień: należy przyznać tylko te działania, które są faktycznie wymagane do wykonania zadania, i żadne inne. Dwa mechanizmy kontrolne pozwalają na zawężenie tych uprawnień.

OOMOL_CONNECT_ALLOWED_ACTIONS przyjmuje listę dozwolonych działań rozdzielonych przecinkami i obsługuje service.* oraz *. OOMOL_CONNECT_BLOCKED_ACTIONS to lista zabronionych działań, która ma priorytet. Ustawienie listy dozwolonych na github.get_current_user,github.list_issues oznacza, że każde inne działanie zostanie odrzucone, niezależnie od żądania agenta, co stanowi różnicę między błędem a incydentem bezpieczeństwa. Tokeny uruchomieniowe nakładają własne reguły działań na reguły globalne, a ich lista allowedProxies jest domyślnie pusta, więc POST /v1/proxy/:service jest odrzucane, dopóki nie zostanie jawnie przyznane. Ten punkt końcowy proxy przekazuje surowe żądanie do dostawcy wraz z dołączonymi danymi uwierzytelniającymi, dlatego należy pozostawić go pustym, chyba że wymaga go konkretny agent.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK domyślnie przyjmuje wartość false, co uniemożliwia połączeniu z samodzielnie hostowanym dostawcą wskazywanie na adresy prywatne, takie jak usługa metadanych chmury pod adresem 169.254.169.254 lub baza danych w tej samej sieci. Należy pozostawić tę opcję wyłączoną. Należy ją włączyć tylko dla dostawcy hostowanego we własnym zakresie.

Tworzenie kopii zapasowej serwera przechowującego wszystkie tokeny

Dwie rzeczy mają znaczenie i każda z nich jest bezużyteczna bez drugiej. Baza danych w /app/data/connect.sqlite wewnątrz wolumenu connector-data przechowuje zabezpieczone poświadczenia. Klucz szyfrujący w .env służy do ich odszyfrowania. Kopia zapasowa wolumenu bez klucza nie pozwala na odzyskanie danych, a sam klucz bez wolumenu jest bezużyteczny, dlatego klucz powinien znajdować się w menedżerze haseł, a wolumen w standardowym cyklu kopii zapasowych.

Zatrzymaj kontener przed skopiowaniem pliku SQLite, ponieważ kopia wykonana w trakcie zapisu może zostać przywrócona jako uszkodzona baza danych.

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

Nazwa wolumenu to nazwa katalogu projektu z dodanym _connector-data, dlatego pierwsze polecenie jest niezbędne: wklej właściwą nazwę do trzeciego polecenia. Wyślij archiwum z VPS, korzystając z kopii zapasowych restic z VPS, co szyfruje dane przed ich wysłaniem, ponieważ archiwum to stanowi magazyn poświadczeń.

Środowisko uruchomieniowe przechowuje ostatnie wykonane akcje jako rekordy audytu, domyślnie 5000 z nich, dzięki czemu konsola może wskazać, który agent wykonał daną operację i kiedy. Ten dziennik jest pierwszym miejscem, które należy sprawdzić, gdy agent zachowuje się w sposób nietypowy. Skieruj również stronę statusu Uptime Kuma na https://connect.example.com/health. Gdy brama przestaje odpowiadać, agenci zgłaszają błędy w niejasny sposób, a wiedza o tym, że brama nie działa, pozwala zaoszczędzić godzinę analizowania danych wyjściowych agenta.

Co ulega awarii i jaki komunikat zobaczysz

redirect_uri_mismatch u dostawcy. Adres źródłowy i zarejestrowany adres URL wywołania zwrotnego (callback URL) różnią się. Porównaj dokładny ciąg znaków z /api/oauth/configs z ustawieniami aplikacji u dostawcy, uwzględniając https w odniesieniu do http oraz ewentualny końcowy ukośnik.

Każde wywołanie /api zwraca błąd 401. Brakuje nagłówka tokena administratora lub zawiera on błąd. Nagłówek to Authorization: Bearer <token>, a konsola internetowa wymaga tego samego tokena.

Kontener działa, a poświadczenia są zapisane otwartym tekstem. Dzieje się tak, gdy OOMOL_CONNECT_ENCRYPTION_KEY nigdy nie dociera do kontenera, ponieważ środowisko uruchomieniowe przechowuje rekordy poświadczeń bez szyfrowania, zamiast odmówić uruchomienia. Zweryfikuj to we własnej instalacji: połącz dostawcę z rozpoznawalnym kluczem API, a następnie wyszukaj go w bazie danych.

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

Wynik powyżej 0 oznacza, że klucz nie jest aktywny. Sprawdź, czy .env znajduje się w tym samym katalogu co compose.yaml oraz czy docker compose config wyświetla odpowiednią wartość. Gdy klucz jest ustawiony, to samo wyszukiwanie zwraca 0, ponieważ rekord jest zabezpieczony za pomocą AES-256-GCM (Advanced Encryption Standard, klucz 256-bitowy, tryb Galois/Counter).

Po przywróceniu danych nic nie ulega deszyfracji. Klucz szyfrujący został zmieniony lub utracony. Zgodnie z założeniami projektowymi nigdy nie jest on zapisywany obok danych, więc nie istnieje ścieżka odzyskiwania ani wsparcie techniczne, które mogłoby pomóc. Połącz ponownie każdego dostawcę. Rotacja jest obsługiwana za pomocą oddzielnej zmiennej klucza oraz polecenia danych w środowisku uruchomieniowym, dlatego przed wykonaniem rotacji zapoznaj się z aktualnymi informacjami o wydaniu (release notes).

Agent zgłasza błąd dotyczący akcji widocznej w katalogu. Wykrywanie i wykonywanie to odrębne procesy. Akcja może pojawić się w search_actions, a mimo to zostać odrzucona przez OOMOL_CONNECT_ALLOWED_ACTIONS, listę zabronionych (denylist) lub reguły przypisane do danego tokena środowiska uruchomieniowego.

Aktualizacje. Wykonaj kopię zapasową wolumenu, zmień tag obrazu na nową wersję, a następnie wykonaj docker compose pull && docker compose up -d. Monitoruj docker compose logs -n 50 connector pod kątem wpisu o migracji, a następnie ponownie uruchom test sprawności (health check) i wykonaj jedną rzeczywistą akcję, zanim ponownie zaufasz systemowi. Wycofanie zmian (rollback) polega na przywróceniu starego tagu, co jest możliwe tylko wtedy, gdy został on wcześniej przypięty (pinned).

FAQ

Czy do samodzielnego hostowania Open Connector potrzebuję domeny publicznej?

W przypadku dostawców korzystających z klucza API – nie: wystarczy brama na 127.0.0.1. W przypadku OAuth – w praktyce tak. Dostawca przekierowuje przeglądarkę na adres URL wywołania zwrotnego (callback URL), więc musi on być rozpoznawalny z poziomu publicznego Internetu, a dostawcy odrzucają zwykłe http:// poza localhost. Przed pierwszym uruchomieniem należy ustawić OOMOL_CONNECT_ORIGIN na swoją nazwę hosta https:// oraz zarejestrować <origin>/oauth/callback w aplikacji OAuth dostawcy.

Co się stanie, jeśli zgubię klucz szyfrujący Open Connector?

Przechowywane poświadczenia nie mogą zostać odszyfrowane i nie ma możliwości ich odzyskania. Klucz celowo nie jest przechowywany wraz z danymi, dzięki czemu nikt, kto posiada bazę danych, nie może jej odczytać – w tym użytkownik. Jedyną opcją jest ustawienie nowego klucza i ponowne połączenie każdego dostawcy. Klucz należy przechowywać w menedżerze haseł, a bazę danych w rotacji kopii zapasowych, ponieważ przywrócenie danych wymaga obu tych elementów.

Czy mój agent AI widzi token dostępu dostawcy?

Nie, jeśli komunikacja odbywa się przez bramę. Agent uwierzytelnia się za pomocą tokena wykonawczego zaczynającego się od oct_, a brama wstrzykuje poświadczenia dostawcy do wychodzącego żądania na serwerze, zwracając jedynie odpowiedź. Dwie sytuacje naruszają tę zasadę: punkt końcowy /v1/proxy/:service, który przekazuje surowe żądania z dołączonymi poświadczeniami (dlatego uprawnienia są domyślnie puste), oraz samodzielne wklejenie klucza API do agenta, co całkowicie pomija bramę.

Czy brama powinna być dostępna z publicznego Internetu?

Dostępny musi być tylko /oauth/callback. Należy opublikować port kontenera na 127.0.0.1, aby reguły NAT w Docker nie wystawiły go poza firewall, a następnie umieścić przed nim reverse proxy. Następnie należy przetestować jedno wywołanie akcji bez nagłówka authorization. Jeśli zakończy się powodzeniem, należy ograniczyć /api, /v1 oraz /mcp na poziomie proxy do adresów używanych przez agentów, aż do momentu, gdy działać będą wyłącznie uwierzytelnione połączenia.

Czy Open Connector jest gotowy do użytku produkcyjnego?

Oprogramowanie jest udostępnione na licencji Apache 2.0 i rozwija się dynamicznie: repozytorium pojawiło się 29 czerwca 2026, a wersja v1.3.3 została wydana 30 lipca 2026, więc każdy numer wersji w tym przewodniku należy traktować jako stan na dzień 1 sierpnia 2026. Należy uruchamiać wersje przypięte do konkretnego tagu wydania, nigdy na latest lub tip, przed każdą aktualizacją czytać informacje o wydaniu oraz posiadać kopię zapasową wolumenu, która została przynajmniej raz przetestowana pod kątem przywracania. Projekt jest solidny dla serwera własnego, a ryzyko wynika z częstych zmian w kodzie, a nie z samej architektury.