Samodzielny hosting Open Connector dla agentów AI

Rola Open Connector w działaniu agenta AI

Samodzielne hostowanie Open Connector pozwala umieścić jedną bramę uwierzytelniającą między agentami AI a wszystkimi wywoływanymi przez nie interfejsami API typu SaaS (Software as a Service), dzięki czemu 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 za pośrednictwem protokołów HTTP oraz MCP (Model Context Protocol).

Problemy pojawiają 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 (scopes). Ręczne integrowanie pięciu dostawców z agentem oznacza konieczność wdrożenia pięciu procedur obsługi 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 awarii opisanej w utrzymywanie sekretów poza zasięgiem agentów AI.

Brama uwierzytelniająca 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 jednego, możliwego do unieważnienia 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ć strukturę: jeden punkt końcowy HTTP na akcję, jedno zapisane połączenie na dostawcę i jeden token na agenta.

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

Zewnętrzna usługa typu connector wykonuje tę samą pracę i przechowuje 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 u dostawcy staje się Twoim naruszeniem. Samodzielne hostowanie 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 określ koszty utrzymania. Ten VPS stanie się najważniejszym serwerem w Twojej infrastrukturze. Przechowuje on w jednym pliku aktywne dane uwierzytelniające do kilkunastu usług, dlatego wymaga traktowania na równi z serwerem menedżera haseł: firewalla otwierającego tylko port 443, braku współdzielonych kont, kopii zapasowej, którą faktycznie przynajmniej raz przywróciłeś, oraz alertów w przypadku braku odpowiedzi serwera. Jeśli nie umieściłbyś na tej maszynie swojego skarbca haseł, nie umieszczaj na niej również usługi connector.

Przypnij wersję przed rozpoczęciem instalacji

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 często ulegają modyfikacjom. 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. Należy przypiąć obraz do konkretnego tagu wydania i aktualizować go w wybranym 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 już obsługuje terminację TLS (transport layer security) dla tej nazwy hosta
• dwa losowe sekrety, wygenerowane poniżej

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

Najpierw wygeneruj sekrety. Klucz szyfrujący zabezpiecza przechowywane poświadczenia. Token administratora chroni konsolę webową oraz cały interfejs /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 przyczyna tego stanu rzeczy znajduje się na liście awarii poniżej.

Teraz przygotuj 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:

Pierwszą zmianą jest przypięta wersja (tag) zamiast latest. Drugą jest port. Plik upstream publikuje 3000:3000, co wiąże usługę ze wszystkimi interfejsami na hoście. Docker zapisuje opublikowane porty w tablicy NAT (network address translation), zanim łańcuch filtrów ufw otrzyma 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ę wyłącznie na interfejsie loopback, a Twoje reverse proxy łączy się z tego samego hosta.

Zapis :? oznacza każdą zmienną jako wymaganą, dzięki czemu 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 na { "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 przed ingerencją w proxy należy sprawdzić logi.

    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 pominięcie powoduje błąd OAuth, który wygląda jak usterka po stronie dostawcy. Środowisko uruchomieniowe buduje swój identyfikator 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 Twoja 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 jest główny 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 (authorization callback URL) 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 (redirect URI), którego środowisko uruchomieniowe oczekuje dla każdego dostawcy. Jest to najszybszy sposób sprawdzenia, czy zmiana źródła (origin) została uwzględniona. Jeśli nadal wyświetlana jest wartość localhost, kontener działa ze starą wartością, a proces OAuth zakończy się niepowodzeniem na ostatnim etapie.

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 (origin) 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 oraz execute_action, zamiast oferować jedno narzędzie na każde API, co pozwala zachować krótką listę narzędzi agenta. Artykuł Uruchamianie serwerów MCP na VPS opisuje stronę kliencką tej konfiguracji.

Przed zakończeniem prac wykonaj jeszcze jedną weryfikację. Powtórz wywołanie akcji z usuniętym nagłówkiem authorization. Szybki start projektu wywołuje /v1 bez żadnego tokena bearer, więc instalacja bez skonfigurowanej autoryzacji wykonawczej pozwoli na uruchamianie akcji każdemu, kto ma dostęp do portu. Jeśli nieuwierzytelnione wywołanie zakończy się powodzeniem, istnieją dwa rozwiązania: skonfigurować tokeny wykonawcze i upewnić się, że anonimowe wywołanie teraz kończy się błędem, lub ograniczyć dostęp do /api, /v1 oraz /mcp na poziomie reverse proxy tylko do adresów, z których łączą się agenci. Jedynie /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. Staje się ona jeszcze szersza, gdy model zaczyna przetwarzać tekst, którego sam nie wygenerował, ponieważ strona zwrócona przez własną instancję SearXNG odpowiadającą na wyszukiwania agenta może zawierać instrukcje skierowane do dowolnych działań, 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 kilka działań, które są faktycznie potrzebne do wykonania zadania, i nic ponadto. Dwa mechanizmy kontrolne pozwalają to ograniczyć.

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. Tokeny uruchomieniowe posiadają własne reguły działań nadrzędne wobec globalnych, 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 poświadczeniami, 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 własnym 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 utrzymywanego we własnym zakresie.

Tworzenie kopii zapasowej serwera przechowującego tokeny

Istotne są dwa elementy, z których każdy jest bezużyteczny bez drugiego. 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 klucz bez wolumenu jest bezużyteczny, dlatego klucz należy przechowywać w menedżerze haseł, a wolumen włączyć do standardowej rotacji 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 składa się z nazwy katalogu projektu oraz _connector-data, dlatego pierwsze polecenie służy do jej ustalenia: wklej właściwą nazwę w trzecim poleceniu. Prześlij archiwum poza VPS, korzystając z kopii zapasowych restic z VPS, co zaszyfruje dane przed ich wysłaniem, ponieważ archiwum to stanowi magazyn poświadczeń.

Środowisko uruchomieniowe przechowuje ostatnie akcje jako rekordy audytu, domyślnie w liczbie 5000, dzięki czemu konsola pozwala sprawdzić, który agent wykonał daną operację i kiedy. Ten dziennik jest pierwszym miejscem, do którego należy zajrzeć, 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 niedostępności bramy pozwala zaoszczędzić godzinę analizy 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) różnią się. Porównaj dokładny ciąg znaków z /api/oauth/configs z ustawieniami aplikacji u dostawcy, uwzględniając https względem http oraz ewentualny końcowy ukośnik.

Każde wywołanie /api zwraca 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. Sprawdź to we własnej instalacji: połącz dostawcę z kluczem API, który możesz rozpoznać, a następnie przeszukaj bazę danych w jego poszukiwaniu.

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 działa, więc sprawdź, czy .env znajduje się w tym samym katalogu co compose.yaml oraz czy docker compose config wyświetla wartość. Gdy klucz jest ustawiony, to samo wyszukiwanie zwraca 0, ponieważ rekord jest zabezpieczony za pomocą AES-256-GCM (zaawansowany standard szyfrowania, klucz 256-bitowy, tryb Galois/counter).

Nic nie odszyfrowuje się po przywróceniu danych. Klucz szyfrujący został zmieniony lub utracony. Z założenia nigdy nie jest zapisywany obok danych, więc nie istnieje ścieżka odzyskiwania ani zgłoszenie serwisowe, które mogłoby pomóc. Połącz ponownie każdego dostawcę. Rotacja jest obsługiwana przez oddzielną zmienną klucza oraz polecenie danych w środowisku uruchomieniowym, więc przed wykonaniem rotacji przeczytaj bieżące informacje o wydaniu (release notes).

Agent otrzymuje błąd dotyczący akcji, którą widzi w katalogu. Odkrywanie i wykonywanie to oddzielne procesy. Akcja może pojawić się w search_actions, a mimo to zostać odrzucona przez OOMOL_CONNECT_ALLOWED_ACTIONS, przez listę zabronionych (denylist) lub przez zasady samego tokena środowiska uruchomieniowego.

Aktualizacje. Wykonaj kopię zapasową wolumenu, zmień tag obrazu na nowe wydanie, a następnie wykonaj docker compose pull && docker compose up -d. Obserwuj docker compose logs -n 50 connector pod kątem linii migracji, a następnie ponownie uruchom test sprawności (health check) i wykonaj jedną rzeczywistą akcję, zanim ponownie zaufasz systemowi. Wycofanie zmian oznacza przywrócenie starego tagu, co działa tylko dlatego, że został on 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 Twój 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 ustaw OOMOL_CONNECT_ORIGIN na swoją nazwę hosta https:// i zarejestruj <origin>/oauth/callback w aplikacji OAuth dostawcy.

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

Zapisane dane uwierzytelniające nie mogą zostać odszyfrowane i nie ma możliwości ich odzyskania. Klucz celowo nigdy nie jest przechowywany wraz z danymi, dzięki czemu nikt posiadający bazę danych nie może jej odczytać, w tym również Ty. Jedyną opcją jest ustawienie nowego klucza i ponowne połączenie każdego dostawcy. Przechowuj klucz 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 może zobaczyć token dostępu dostawcy?

Nie, gdy wywołuje go przez bramę. Agent uwierzytelnia się za pomocą tokena wykonawczego zaczynającego się od oct_, a brama wstrzykuje dane uwierzytelniające dostawcy do żądania wychodzącego na serwerze, zwracając tylko odpowiedź. Dwie sytuacje naruszają tę zasadę: punkt końcowy /v1/proxy/:service, który przekazuje surowe żądania z dołączonymi danymi uwierzytelniającymi (dlatego uprawnienia zaczynają się jako puste), oraz samodzielne wklejenie klucza API do agenta, co całkowicie pomija bramę.

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

Tylko /oauth/callback musi być dostępny. Opublikuj port kontenera na 127.0.0.1, aby reguły NAT w Docker nie mogły wystawić go poza Twój firewall, i umieść przed nim reverse proxy. Następnie przetestuj jedno wywołanie akcji bez nagłówka authorization. Jeśli się powiedzie, ogranicz /api, /v1 oraz /mcp na poziomie proxy do adresów używanych przez Twoich agentów, aż do momentu, gdy działać będą tylko uwierzytelnione połączenia.

Czy Open Connector jest gotowy do użycia produkcyjnego?

Jest objęty licencją Apache 2.0 i rozwija się szybko: repozytorium pojawiło się 29 czerwca 2026, a wersja v1.3.3 została wydana 30 lipca 2026, więc traktuj każdy numer wersji w tym przewodniku jako stan na dzień 1 sierpnia 2026. Uruchamiaj go przypiętego do konkretnego tagu wydania, nigdy na latest lub tip, czytaj informacje o wydaniu przed każdą aktualizacją i przechowuj kopię zapasową wolumenu, którą przynajmniej raz przetestowałeś pod kątem przywracania. Projekt jest solidny dla serwera, którego jesteś właścicielem, a ryzyko wynika z częstych zmian wersji, a nie z samej architektury.