Open Connector self-hosting dla agentów AI

Funkcje Open Connector dla agenta AI

Samodzielne hostowanie Open Connector umieszcza jedną bramę uwierzytelniania między agentami AI a każdym wywoływanym przez nie interfejsem API typu software as a service (SaaS). Agent nigdy nie przechowuje tokenu dostawcy. Jest to brama open source firmy OOMOL Lab, udostępniana na licencji Apache 2.0. Działa jako jeden kontener, przechowuje stan w jednym pliku SQLite oraz udostępnia operacje dostawców przez HTTP i MCP (model context protocol).

Problemy zaczynają się przy drugiej integracji. Każdy dostawca ma własny przepływ OAuth (open authorization), własny czas życia tokenu odświeżania oraz własne nazwy zakresów uprawnień. Ręczne podłączenie pięciu dostawców do agenta oznacza pięć programów obsługi przekierowań, pięć magazynów poświadczeń oraz pięć pętli odświeżania, które muszą działać przed wygaśnięciem tokenu. Prawie nikt nie pisze takiego kodu. Zamiast tego generowany jest jeden długoterminowy osobisty token dostępu dla każdej usługi i wklejany do konfiguracji agenta, pliku środowiskowego lub samego promptu. Token ten może następnie odczytać każde narzędzie uruchamiane przez agenta i trafia on do transkrypcji. Opisuje to awaria uniemożliwianie agentom AI dostępu do danych uwierzytelniających.

Brama uwierzytelniania rozdziela poświadczenie na dwie części. Brama przechowuje poświadczenie dostawcy i obsługuje przepływ OAuth. Agent otrzymuje token wykonawczy, który jest ważny wyłącznie względem bramy. Gdy agent wywołuje operację, brama ładuje zapisane poświadczenie, wstrzykuje je po stronie serwera do żądania wychodzącego i zwraca wyłącznie treść odpowiedzi. Agent nigdy nie otrzymuje tokenu dostępu dostawcy, więc wyciek transkrypcji agenta oznacza utratę jednego tokenu wykonawczego, który można unieważnić, a nie całego konta GitHub.

Katalog zawiera według deklaracji ponad 1,000 dostawców i 10,000 gotowych operacji. Jest to wartość podawana przez sam projekt, której nie można niezależnie zweryfikować z zewnątrz. Można natomiast zweryfikować strukturę: jeden punkt końcowy HTTP dla każdej operacji, jedno zapisane połączenie dla każdego dostawcy oraz jeden token dla każdego agenta.

Dlaczego warto samodzielnie hostować Open Connector zamiast korzystać z hostowanej usługi konektora

Hostowana usługa konektora wykonuje tę samą pracę i przechowuje tokeny odświeżania dla każdego podłączonego dostawcy. Token odświeżania Google lub GitHub jest długoterminowym kluczem kryptograficznym do poczty i repozytoriów. Zwykle pozostaje ważny po zmianie hasła. Naruszenie zabezpieczeń tej usługi oznacza naruszenie zabezpieczeń użytkownika. Samodzielne hostowanie przenosi te dane do SQLite na maszynie wynajmowanej i administrowanej przez użytkownika. Dane są chronione kluczem, który nigdy nie opuszcza tej maszyny.

Przed rozpoczęciem należy jasno określić koszty. Ten VPS staje się najcenniejszym serwerem użytkownika. Przechowuje działające dane uwierzytelniające kilkunastu usług w jednym pliku. Wymaga zatem takiej samej ochrony jak host menedżera haseł: zapory sieciowej udostępniającej wyłącznie port 443, bez współdzielonych danych logowania, kopii zapasowej, z której wykonano już co najmniej jedno odtworzenie, oraz alertu wysyłanego po przerwaniu odpowiedzi serwera. Jeśli na tej maszynie nie zostałby umieszczony magazyn haseł, nie należy umieszczać na niej konektora.

Przypnij wersję przed rozpoczęciem instalacji

Open Connector jest nowym projektem. Repozytorium pojawiło się po raz pierwszy 29 June 2026, a 1 August 2026 najnowszym wydaniem oznaczonym tagiem jest v1.3.3, opublikowane 30 July 2026 i również opatrzone tagiem latest. Rejestr publikuje także tag tip, zbudowany na podstawie najnowszego zatwierdzenia w main.

W tak nowym projekcie zmienne tagi często wskazują nowsze wersje. docker compose pull, który przeskoczy o dwie wersje, może zmienić endpoint wymagany przez agenta, a diagnozowanie problemu zostanie błędnie potraktowane jako problem z agentem. Przypnij obraz do tagu wydania i aktualizuj go wtedy, gdy zostanie podjęta taka decyzja, po zapoznaniu się z informacjami o wydaniu.

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

Przed uruchomieniem kontenera potrzebne są:

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

W artykule Traefik jako odwrotne proxy dla wielu aplikacji Docker Compose opisano konfigurację proxy. Konfigurację obsługi certyfikatów od początku do końca dla pojedynczej aplikacji opisano w przewodniku n8n na VPS z Dockerem i HTTPS.

Najpierw wygeneruj sekrety. Klucz szyfrowania chroni zapisane dane uwierzytelniające. Token administratora zabezpiecza konsolę internetową i całą powierzchnię /api. Żaden z nich nie ma wartości domyślnej, a środowisko uruchomieniowe uruchamia się bez nich bez zgłaszania błędu.

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 teraz obie wartości do menedżera haseł, przed pierwszym uruchomieniem. Klucza szyfrowania nie można odzyskać. Przyczyna została opisana na dalszej liście problemów.

Teraz compose.yaml. Różni się od przykładu dostarczonego przez upstream w dwóch miejscach. Obie zmiany mają znaczenie.

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ęty tag zamiast latest. Druga zmiana dotyczy portu. Plik upstream publikuje 3000:3000, co wiąże port ze wszystkimi interfejsami hosta. Docker zapisuje opublikowane porty w tabeli NAT (network address translation), zanim pakiet trafi do łańcucha filtrów ufw. Dlatego ufw deny 3000 nie zamyka tego portu. Ten problem opisano w dlaczego porty Dockera omijają ufw. Zapis 127.0.0.1:3000:3000 publikuje port wyłącznie na interfejsie loopback, a odwrotne proxy łączy się z tego samego hosta.

Znacznik :? oznacza każdą zmienną jako wymaganą. Stos odmawia uruchomienia, gdy brakuje .env, zamiast uruchamiać się z niezaszyfrowanymi danymi uwierzytelniającymi. Przechowywanie wartości w .env, a nie w pliku Compose, jest wzorcem opisanym w plikach env i sekretach 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 } po uruchomieniu środowiska. ss musi wyświetlić 127.0.0.1:3000. Wiersz zawierający 0.0.0.0:3000 oznacza, że mapowanie portu nadal pochodzi z pliku upstream, a brama odpowiada bezpośrednio całemu Internetowi. Odrzucenie połączenia podczas sprawdzania stanu oznacza, że kontener jeszcze nie nasłuchuje. Przed zmianą konfiguracji proxy odczytaj 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 rzeczywistej nazwy hosta

OOMOL_CONNECT_ORIGIN to ustawienie, które jest często pomijane. Jego pominięcie powoduje awarię OAuth wyglądającą jak błąd dostawcy. Środowisko wykonawcze tworzy identyfikator URI przekierowania na podstawie tego źródła, w postaci <origin>/oauth/callback. Jeśli źródło nie jest ustawione, domyślnie przyjmuje wartość http://localhost:3000. W efekcie środowisko wykonawcze wysyła do dostawcy identyfikator URI przekierowania http://localhost:3000/oauth/callback, podczas gdy w aplikacji OAuth zarejestrowano https://connect.example.com/oauth/callback. Te dwa ciągi są różne, dlatego GitHub odpowiada:

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

Dostawca OAuth przekierowuje przeglądarkę z powrotem do tego identyfikatora URI. Oznacza to, że musi to być adres dostępny z zewnętrznej sieci. Dostawcy odrzucają zwykły http:// w każdym przypadku poza localhost. Z tego powodu to wdrożenie wymaga nazwy hosta i certyfikatu. Źródło należy ustawić przed pierwszym uruchomieniem, ponieważ wartość jest odczytywana podczas uruchamiania. Po zmodyfikowaniu .env lub compose.yaml należy ponownie uruchomić docker compose up -d, aby zastosować zmianę.

Połącz pierwszego dostawcę za pośrednictwem OAuth

Najpierw utwórz aplikację OAuth u dostawcy. W GitHub wybierz kolejno Settings, Developer settings, OAuth Apps i New OAuth App. Ustaw adres URL wywołania zwrotnego autoryzacji na https://connect.example.com/oauth/callback. Zachowaj identyfikator klienta i klucz tajny klienta.

Każde wywołanie /api zawiera token administratora, dlatego należy wyeksportować go raz na potrzeby sesji powłoki.

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

Ta lista pokazuje identyfikator URI przekierowania oczekiwany przez środowisko wykonawcze dla każdego dostawcy. Jest to najszybszy sposób sprawdzenia, czy ustawienie origin zaczęło obowiązywać. 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 dane uwierzytelniające 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 je w przeglądarce i zaakceptuj zakresy uprawnień. Następnie dostawca przekieruje przeglądarkę z powrotem do /oauth/callback, gdzie środowisko wykonawcze wymieni kod i zapisze dane uwierzytelniające. Konsola internetowa dostępna pod adresem origin prowadzi przez te same czynności za pomocą formularza, z użyciem tego samego tokena administratora. Dostawcy korzystający ze zwykłego klucza API pomijają cały ten proces: PUT /api/connections/<service> z {"authType":"api_key","values":{"apiKey":"..."}} zapisuje klucz bezpośrednio.

Nadaj każdemu agentowi token środowiska wykonawczego, nigdy poświadczenie

Agent uwierzytelnia się w bramie za pomocą tokenu środowiska wykonawczego, który generuje 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 zaczynający się od oct_. Należy wydać po jednym tokenie dla każdego agenta i nazwać go zgodnie z nazwą tego agenta, ponieważ unieważnienie tokenu, którego nie można zidentyfikować, oznacza unieważnienie wszystkich tokenów. Agent wywołuje następnie działania za pośrednictwem zwykłego 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":{}}'

Prawidłowa odpowiedź jest kopertą, której pole success ma wartość true, a dane dostawcy znajdują się w polu data. Token GitHub nie występuje nigdzie w tej odpowiedzi. W przypadku klienta MCP należy wskazać https://connect.example.com/mcp i użyć tego samego nagłówka bearer. Brama udostępnia wtedy narzędzia wykrywania, takie jak search_actions i execute_action, zamiast osobnego narzędzia dla każdego API. Dzięki temu lista narzędzi agenta pozostaje niewielka. W artykule Uruchamianie serwerów MCP na VPS opisano konfigurację po stronie klienta.

Przed uznaniem konfiguracji za zakończoną należy wykonać jeszcze jedną kontrolę. Należy ponownie wywołać działanie po usunięciu nagłówka authorization. Własny przewodnik szybkiego startu projektu wywołuje /v1 bez żadnego bearer tokenu. Oznacza to, że instalacja bez skonfigurowanego uwierzytelniania środowiska wykonawczego będzie wykonywać działania dla każdej osoby, która może uzyskać dostęp do portu. Jeśli wywołanie nieuwierzytelnione zakończy się powodzeniem, dostępne są dwa rozwiązania: skonfigurować tokeny środowiska wykonawczego i potwierdzić, że wywołanie anonimowe kończy się teraz niepowodzeniem albo ograniczyć dostęp do /api, /v1 i /mcp na odwrotnym serwerze proxy do adresów, z których korzystają agenci. Tylko /oauth/callback musi pozostać dostępne z całego świata, ponieważ jest to jedyna ścieżka wymagana przez przekierowanie przeglądarki dostawcy.

Ograniczenie listy działań do tych wymaganych przez agenta

Brama z tysiącem dostawców udostępnia modelowi językowemu zbyt szeroki zakres działania. Dwa mechanizmy pozwalają go ograniczyć.

OOMOL_CONNECT_ALLOWED_ACTIONS przyjmuje listę dozwolonych elementów rozdzielonych przecinkami oraz obsługuje service.* i *. OOMOL_CONNECT_BLOCKED_ACTIONS to lista blokowanych elementów, która ma pierwszeństwo. Ustawienie listy dozwolonych na github.get_current_user,github.list_issues powoduje odrzucenie wszystkich pozostałych działań, niezależnie od żądań agenta. To różnica między pomyłką a incydentem. Tokeny używane w czasie działania mają własne reguły działań, które obowiązują dodatkowo do reguł globalnych. Ich lista allowedProxies jest początkowo pusta, dlatego POST /v1/proxy/:service zostaje odrzucone do momentu jego jawnego przyznania. Ten punkt końcowy proxy przekazuje dostawcy surowe żądanie wraz z dołączonymi poświadczeniami. Należy pozostawić tę listę pustą, chyba że konkretny agent jej potrzebuje.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK ma domyślnie wartość false. Zapobiega to kierowaniu połączenia z dostawcą hostowanym samodzielnie na adres prywatny, taki jak usługa metadanych chmury pod adresem 169.254.169.254, lub na bazę danych w tej samej sieci. Należy pozostawić tę opcję wyłączoną. Należy ją włączyć tylko dla dostawcy hostowanego samodzielnie.

Wykonaj kopię zapasową systemu zawierającego wszystkie tokeny

Liczą się dwie rzeczy i każda z nich jest bezużyteczna bez drugiej. Baza danych w /app/data/connect.sqlite, znajdująca się w wolumenie connector-data, zawiera zapieczętowane dane uwierzytelniające. Klucz szyfrujący w .env służy do ich odpieczętowania. Kopia zapasowa wolumenu bez klucza nie pozwala niczego odtworzyć, a sam klucz bez wolumenu również nie pozwala niczego odtworzyć. Klucz należy przechowywać w menedżerze haseł, a wolumen objąć standardowym harmonogramem tworzenia kopii zapasowych.

Zatrzymaj kontener przed skopiowaniem pliku SQLite, ponieważ kopia wykonana podczas zapisu może zostać odtworzona 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 katalog projektu wraz z _connector-data. Dlatego pierwsze polecenie znajduje się w tym miejscu: wklej rzeczywistą nazwę do trzeciego polecenia. Wyślij archiwum poza VPS za pomocą kopii zapasowych restic z VPS, które szyfrują je przed wysłaniem, ponieważ archiwum zawiera magazyn danych uwierzytelniających.

Środowisko wykonawcze przechowuje najnowsze uruchomienia operacji jako rekordy audytowe — domyślnie 5,000 rekordów — dzięki czemu konsola może wskazać, który agent wykonał daną operację i kiedy. Ten dziennik należy sprawdzić w pierwszej kolejności, gdy agent działa nieprawidłowo. Skonfiguruj również stronę stanu Uptime Kuma dla https://connect.example.com/health. Gdy brama przestaje odpowiadać, agenty kończą działanie w niejasny sposób, a informacja o niedostępności bramy pozwala zaoszczędzić godzinę analizy danych wyjściowych agenta.

Co ulega awarii i jaki komunikat zostanie wyświetlony

redirect_uri_mismatch u dostawcy. Adres źródłowy i zarejestrowany adres URL wywołania zwrotnego różnią się. Należy porównać dokładny ciąg z /api/oauth/configs z ustawieniami aplikacji u dostawcy, w tym https z http oraz ewentualny końcowy ukośnik.

Każde wywołanie /api zwraca 401. Brakuje nagłówka z tokenem administratora albo jego nazwa jest błędna. Nagłówek to Authorization: Bearer <token>, a konsola internetowa wymaga tego samego tokena.

Kontener działa, a dane uwierzytelniające są przechowywane w postaci jawnego tekstu. Dzieje się tak, gdy OOMOL_CONNECT_ENCRYPTION_KEY nie dociera do kontenera, ponieważ środowisko uruchomieniowe przechowuje rekordy danych uwierzytelniających bez szyfrowania zamiast odmawiać uruchomienia. Należy potwierdzić to we własnej instalacji: połączyć dostawcę za pomocą rozpoznawalnego klucza API, a następnie wyszukać 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

Wartość większa niż 0 oznacza, że klucz nie jest używany. Należy sprawdzić, czy .env znajduje się w tym samym katalogu co compose.yaml oraz czy docker compose config wyświetla tę wartość. Po ustawieniu klucza to samo wyszukiwanie zwraca 0, ponieważ rekord jest zabezpieczony za pomocą AES-256-GCM (Advanced Encryption Standard, klucz 256-bitowy, tryb Galois/counter).

Po odtworzeniu niczego nie można odszyfrować. Klucz szyfrowania został zmieniony albo utracony. Z założenia nie jest on nigdy zapisywany obok danych, dlatego nie istnieje ścieżka odzyskiwania i zgłoszenie do pomocy technicznej nie rozwiąże problemu. Należy ponownie połączyć każdego dostawcę. Rotacja jest obsługiwana za pomocą oddzielnej zmiennej klucza i polecenia danych w środowisku uruchomieniowym, dlatego przed rozpoczęciem rotacji należy zapoznać się z bieżącymi informacjami o wydaniu.

Agent zgłasza błąd dotyczący działania widocznego w katalogu. Wykrywanie i wykonywanie to odrębne etapy. Działanie może być widoczne w search_actions, a mimo to zostać odrzucone przez OOMOL_CONNECT_ALLOWED_ACTIONS, listę blokad lub reguły danego tokena środowiska uruchomieniowego.

Aktualizacje. Należy utworzyć kopię zapasową woluminu, zmienić znacznik obrazu na nową wersję, a następnie wykonać docker compose pull && docker compose up -d. Należy monitorować docker compose logs -n 50 connector pod kątem wpisu dotyczącego migracji, a następnie ponownie uruchomić test poprawności działania i jedno rzeczywiste działanie, zanim instalacja zostanie ponownie uznana za zaufaną. Wycofanie aktualizacji polega na przywróceniu starego znacznika. Działa to wyłącznie dlatego, że znacznik został przypięty.

FAQ

Czy do samodzielnego hostowania Open Connector potrzebna jest publiczna domena?

W przypadku dostawców korzystających z klucza API nie: wystarczy brama na 127.0.0.1. W przypadku OAuth jest ona w praktyce wymagana. Dostawca przekierowuje przeglądarkę na adres URL wywołania zwrotnego, dlatego ten adres musi być dostępny z publicznego Internetu. Dostawcy odrzucają zwykły http:// poza localhost. Przed pierwszym uruchomieniem należy ustawić OOMOL_CONNECT_ORIGIN na nazwę hosta https:// i zarejestrować <origin>/oauth/callback w aplikacji OAuth dostawcy.

Co się stanie po utracie klucza szyfrowania Open Connector?

Zapisanych danych uwierzytelniających nie można odszyfrować i nie ma procedury odzyskiwania. Klucz celowo nie jest przechowywany razem z danymi, dlatego nikt mający dostęp do bazy danych nie może ich odczytać, również użytkownik. Jedynym rozwiązaniem jest ustawienie nowego klucza i ponowne połączenie każdego dostawcy. Klucz należy przechowywać w menedżerze haseł, a bazę danych uwzględnić w harmonogramie kopii zapasowych, ponieważ do odtworzenia potrzebne są oba elementy.

Czy agent AI może zobaczyć token dostępu dostawcy?

Nie, jeśli wywołuje dostawcę za pośrednictwem bramy. Agent uwierzytelnia się za pomocą tokenu uruchomieniowego zaczynającego się od oct_. Brama dodaje dane uwierzytelniające dostawcy do żądania wychodzącego na serwerze i zwraca wyłącznie odpowiedź. Tę właściwość naruszają dwa przypadki: punkt końcowy /v1/proxy/:service, który przekazuje surowe żądania z dołączonymi danymi uwierzytelniającymi użytkownika i którego uprawnienia domyślnie są puste z uzasadnionego powodu, oraz wklejenie klucza API bezpośrednio do agenta, co całkowicie omija bramę.

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

Dostępny publicznie musi być wyłącznie /oauth/callback. Port kontenera należy opublikować na 127.0.0.1, aby reguły NAT platformy Docker nie mogły udostępnić go poza zaporą sieciową, a przed nim umieścić odwrotny serwer 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 i /mcp na serwerze proxy do adresów używanych przez agentów, aż będą działać wyłącznie uwierzytelnione wywołania.

Czy Open Connector nadaje się już do użycia produkcyjnego?

Oprogramowanie jest objęte licencją Apache 2.0 i szybko się rozwija: repozytorium utworzono 29 June 2026, a wersję v1.3.3 wydano 30 July 2026. Dlatego każdą wersję podaną w tym przewodniku należy traktować jako stan z 1 August 2026. Należy uruchamiać oprogramowanie z przypiętym tagiem wydania, nigdy z latest ani tip, przed każdą aktualizacją czytać informacje o wydaniu oraz przechowywać kopię zapasową woluminu, którą przynajmniej raz odtworzono. Projekt jest solidny w przypadku serwera pozostającego pod kontrolą użytkownika. Ryzyko wynika ze zmienności wersji, a nie z architektury.