Jak samodzielnie hostować OpenBot AI na własnym VPS

Co zyskujesz, hostując samodzielnie współpracowników OpenBot AI

Samodzielne hostowanie współpracowników OpenBot AI polega na uruchomieniu jednego serwera bramy oraz jednego kontenera na każdego bota na sprzęcie, którym zarządzasz. Każdy kontener bota posiada własną przeglądarkę Chromium oraz własny wolumen obszaru roboczego, z profilem przeglądarki zachowującym dane między sesjami. Każde działanie podejmowane przez bota na komputerze, w pliku, na serwerze MCP (model context protocol) lub w komponencie interfejsu użytkownika przechodzi przez bramę, która weryfikuje je pod kątem polityki przed wykonaniem i rejestruje po jego zakończeniu.

OpenBot jest publikowany przez CopilotKit na licencji MIT pod adresem github.com/CopilotKit/openbot. Pierwsze otagowane wydanie, v0.0.1, zostało opublikowane 17 sierpnia 2026 roku, a projekt określa się jako wersję alfa w fazie aktywnego rozwoju. Należy traktować go jako przemyślaną konstrukcję z wczesnymi niedociągnięciami.

Ciekawy element tej architektury jest jednocześnie jej kosztownym aspektem. Przeglądarka dla każdego agenta to koszt pamięci RAM, o którym większość osób zapomina przy planowaniu, dlatego przed instalacją należy odpowiednio dobrać zasoby.

W jaki sposób bramka podejmuje każdą akcję

Serwer API na porcie 3001 stanowi jedyną ścieżkę dostępu do komputera bota. Zanim zostanie wykonana akcja w przeglądarce, bramka ustala cel na podstawie zrzutu strony, ocenia reguły polityki CEL (common expression language) w odniesieniu do kontekstu, zapisuje wiersz audytu zawierający decyzję i dopiero wtedy wywołuje kontener. Jeśli po tym kroku wykonanie zakończy się niepowodzeniem, zapisywany jest drugi wiersz. Dokumentacja jasno określa granicę: komputer nie decyduje o polityce, bramka serwera stanowi granicę akcji.

Polityka opiera się na domyślnej odmowie (deny-by-default), a reguły odmowy są oceniane przed regułami zezwolenia. Kierunek niepowodzenia ma większe znaczenie niż składnia reguły. Brak polityki nie zezwala na nic, a uszkodzona reguła skutkuje zablokowaniem, niezależnie od tego, czy jest to reguła odmowy, czy zezwolenia. Dzięki temu błąd w polityce powoduje jedynie zatrzymanie bota, a nie jego niekontrolowane działanie na kontach.

Ścieżka audytu znajduje się w PostgreSQL, więc przetrwa restart. Przekazanie kontroli jest rejestrowane jako computer.help_requested, computer.control_taken oraz computer.control_released; w ten sposób można sprawdzić, kiedy bot prosi o pomoc człowieka oraz kiedy człowiek przejmuje kontrolę z powrotem. Sekrety są rejestrowane jako liczba znaków, nigdy jako wartości. Operacje na plikach rejestrują ścieżkę i rozmiar, nigdy zawartość. Jeśli wymagana jest ta sama granica kontroli bez przeglądarki w tle, ograniczanie akcji agenta AI za pomocą zatwierdzeń opisuje ten węższy przypadek.

Koszt pamięci RAM i miejsca na dysku dla jednego bota

Projekt publikuje zmierzone wartości dla pojedynczego bota na architekturze arm64. Są to jedyne liczby dotyczące rozmiaru, jakie udostępnia OpenBot. Opisują one jednego bota na jednej architekturze, dlatego należy traktować je jako punkt wyjścia, a nie jako plan wydajnościowy.

[
  {
    "label": "Measured, one Bot",
    "memory_gb": 0.55,
    "disk_gb": 5.3,
    "vcpu": 0.06
  },
  {
    "label": "Documented minimum",
    "memory_gb": 2,
    "disk_gb": 8,
    "vcpu": 1
  },
  {
    "label": "Documented recommended",
    "memory_gb": 4,
    "disk_gb": 10,
    "vcpu": 2
  }
]

Szczytowe zużycie pamięci dla jednego bota zmierzono na poziomie 0.55 GB, podczas gdy udokumentowane minimum wynosi 2 GB, a zalecana wartość to 4 GB. Różnica między pomiarem a minimum stanowi margines na wzrost zapotrzebowania Chromium pod obciążeniem, ponieważ zużycie pamięci przez przeglądarkę zależy od liczby otwartych stron, a nie od procesu w stanie spoczynku. Zużycie procesora w stanie bezczynności jest bliskie zeru i wynosi 0.06 rdzenia w górnej granicy pomiaru, więc to nie procesor jest głównym kosztem. Jest nim miejsce na dysku. Sam obraz zajmuje 5.3 GB, przy zalecanej objętości wolumenu 10 GB. Tak duży rozmiar wynika z faktu, że obraz zawiera binarne pliki Playwright dla Firefox i WebKit obok Chromium.

Powyższe dane nie określają kosztu utrzymania kilku botów jednocześnie, a projekt nie publikuje takich szacunków. Należy przeprowadzić własne pomiary. Uruchom jednego bota, przydziel mu rzeczywiste zadanie z otwartą stroną i monitoruj kontener podczas pracy.

docker stats --no-stream
free -m

Przyjmij wartość z kolumny MEM USAGE dla kontenera bota jako koszt jednostkowy, dodaj do tego wymagania gateway oraz PostgreSQL, a następnie pomnóż wynik przez liczbę botów, które mają działać jednocześnie. Bezczynny bot nadal utrzymuje proces przeglądarki, więc mnożnik dotyczy wszystkich istniejących botów, a nie tylko tych aktualnie zajętych. Obliczenia są identyczne z tymi, które stosuje się przy dobieraniu pamięci RAM i procesora dla VPS z agentem programistycznym, a kwestie związane z przeglądarką zostały omówione w uruchamianiu przeglądarki headless dla agentów na VPS.

Jeden szczegół dotyczący Chromium wpływa na małe plany. OpenBot uruchamia Chromium z flagą --disable-dev-shm-usage, dzięki czemu przeglądarka zapisuje dane w /tmp zamiast w /dev/shm. Pozwala to uniknąć awarii występujących na hostach z małą partycją /dev/shm i przenosi obciążenie na główny system plików, co stanowi kolejny powód, dla którego zalecany rozmiar dysku jest większy niż rozmiar samego obrazu.

Jak samodzielnie hostować OpenBot na VPS?

Wymagane są Docker, Bun 1.3 lub nowszy, projekt CopilotKit Intelligence oraz klucz API modelu. Dokumentacja programistyczna wymaga również obecności lsof, python3 oraz curl na serwerze. Należy sklonować otagowane wydanie zamiast main, ponieważ main w projektach alfa zmienia się bez ostrzeżenia.

git clone --branch v0.0.1 https://github.com/CopilotKit/openbot.git
cd openbot
cp .env.example .env

Skonfiguruj projekt Intelligence. Poniższe trzy polecenia zapisują klucz środowiska wykonawczego oraz token licencyjny w pliku środowiskowym.

npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
npx --yes copilotkit@latest license --write

Wygeneruj klucz szyfrujący przechowywane poświadczenia i umieść wynik w .env jako KEY_ENCRYPTION_KEY. Dodaj swój OPENAI_API_KEY w tym samym pliku lub ustaw BOT_PROVIDER na anthropic albo google wraz z pasującym kluczem.

openssl rand -base64 32

Następnie przeprowadź instalację i uruchomienie.

bun install
bash scripts/start.sh

scripts/start.sh uruchamia usługi Docker, wykonuje migracje bazy danych, startuje serwer oraz aplikację, a także sprawdza ich stan. Po zakończeniu operacji aplikacja odpowiada na porcie 3010, a API na porcie 3001. Skrypt zgłasza konflikty portów i pomija już działające usługi, więc jego ponowne uruchomienie jest bezpieczne.

Przed wystawieniem usług na zewnątrz sprawdź ich działanie bezpośrednio z poziomu serwera.

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3010
ss -ltnp | grep -E ':(3010|3001|4100|4500|5432)'

200 w odpowiedzi na pierwsze polecenie oznacza, że aplikacja działa. Drugie polecenie wskazuje adresy, do których przypisane są porty; jest to kluczowa informacja w środowisku VPS. Wiersz zawierający 127.0.0.1:3001 oznacza, że usługa jest dostępna tylko lokalnie. Wiersz zawierający 0.0.0.0:3001 oznacza, że usługa jest dostępna dla każdego, kto posiada trasę do serwera.

Pojedynczy obraz kontenera

Dokumentacja wdrożeniowa udostępnia również pojedynczy obraz zawierający aplikację, API oraz Chromium, działający na porcie 3001.

docker build -t openbot .
docker run -p 127.0.0.1:3001:3001 --env-file .env \
  -e EMBEDDED_POSTGRES=on -v openbot-data:/var/lib/postgresql/data openbot

EMBEDDED_POSTGRES=on uruchamia PostgreSQL wewnątrz kontenera i wykonuje migracje podczas startu. Nazwany wolumen przechowuje historię audytu po ponownym wdrożeniu; bez niego każda przebudowa usuwa tę historię. Jeśli skierujesz DATABASE_URL na zewnętrzną bazę danych, musisz włączyć na niej rozszerzenie vector. Usługi zarządzane, takie jak RDS, Cloud SQL czy Azure Database, obsługują to rozszerzenie, ale żadna z nich nie włącza go automatycznie. W rezultacie migracja na świeżej bazie danych zakończy się niepowodzeniem, ponieważ typ kolumny vector jeszcze nie istnieje.

W przypadku zewnętrznej bazy danych wykonuj migracje jako krok wydania (release step).

docker run --rm --env-file .env openbot \
  sh -c "cd /app/server && bun x drizzle-kit migrate --config=drizzle.config.ts"

Ten obraz celowo nie publikuje portu przeglądarki. Pomija również supervisor, ponieważ wymaga on dostępu do gniazda Docker, czego platformy typu serverless nie oferują. Bez supervisora każdy bot współdzieli jedną przeglądarkę, a tym samym jeden zestaw danych logowania. Eliminuje to izolację, która uzasadnia uruchamianie osobnych kontenerów dla każdego bota. Jeśli celem jest posiadanie oddzielnych danych logowania dla każdego bota, uruchom stos compose z ustawionymi zmiennymi COMPUTER_SUPERVISOR_URL oraz SUPERVISOR_TOKEN na hoście, na którym akceptujesz związane z tym ryzyko. Proces mający dostęp do gniazda Docker może uruchomić uprzywilejowany kontener, co w praktyce oznacza dostęp root na hoście. Jest to wystarczający powód, aby utrzymywać OpenBot na dedykowanej maszynie, zgodnie z zasadą udostępniania agentom programistycznym tymczasowej maszyny wirtualnej.

Dlaczego OPENBOT_SINGLE_USER jest ustawieniem dla laptopa

.env.example jest dostarczany z OPENBOT_SINGLE_USER=true. To ustawienie traktuje każde żądanie jako żądanie administratora i całkowicie pomija logowanie. Na laptopie jest to udogodnienie, ponieważ jedynym klientem, który może uzyskać dostęp do portu, jesteś Ty. Na serwerze VPS oznacza to, że pierwsza osoba, która dotrze do portu 3010, staje się administratorem systemu przechowującego zaszyfrowane poświadczenia i obsługującego przeglądarkę już zalogowaną na Twoje konta.

Istnieją dwa poprawne sposoby uruchomienia tej aplikacji. Zachowaj OPENBOT_SINGLE_USER=true, powiąż wszystkie porty z 127.0.0.1 i uzyskuj dostęp do aplikacji wyłącznie przez tunel SSH lub prywatny interfejs sieciowy.

ssh -N -L 3010:127.0.0.1:3010 -L 3001:127.0.0.1:3001 you@your-vps

Aplikacja jest wtedy dostępna pod adresem http://localhost:3010 w Twojej przeglądarce, co jest uznawane za bezpieczny kontekst, dzięki czemu pliki cookie logowania oraz funkcje przeglądarki wymagane przez podgląd na żywo działają poprawnie. Drugim sposobem jest wyłączenie trybu single-user i skonfigurowanie rzeczywistego dostawcy tożsamości. Obsługiwane są Google, Microsoft Entra, Okta, SAML oraz OIDC. Każdy dostawca wymaga również BETTER_AUTH_SECRET o długości co najmniej 32 znaków, BETTER_AUTH_URL ustawionego na publiczny bazowy adres URL API dla wywołań zwrotnych OAuth, INITIAL_ADMIN_EMAILS oraz TRUSTED_ORIGINS. Poświadczenia dostawcy muszą być kompletne, ponieważ niepełna konfiguracja dostawcy powoduje zatrzymanie procesu uruchamiania zamiast powrotu do otwartego dostępu.

Jeśli aplikacja jest dostępna pod publiczną nazwą domenową, należy umieścić przed nią TLS (transport layer security). Strona serwowana przez zwykłe http:// na dowolnym hoście innym niż localhost nie stanowi bezpiecznego kontekstu, dlatego pliki cookie oznaczone jako Secure nie są zapisywane, a logowanie kończy się niepowodzeniem, co może być mylnie interpretowane jako błąd w OpenBot.

Zabezpieczanie portów niskiego poziomu

Notatka dotycząca bezpieczeństwa OpenBot wskazuje, że punkty końcowe usług niskiego poziomu są chronione tokenami, powinny pozostać prywatne i nie należy ich używać do omijania bramy. Tokeny stanowią drugą linię ochrony. Pierwszą jest całkowity brak możliwości nawiązania połączenia z portem.

Agent-computer nasłuchuje na porcie 4100 i wymaga COMPUTER_TOKEN. Punkty końcowe bota nasłuchują na portach 4200 oraz 4201. Supervisor nasłuchuje na porcie 4500 na hoście oraz 4300 wewnątrz swojego kontenera. PostgreSQL nasłuchuje na porcie 5432. Żaden z tych portów nie powinien być dostępny na publicznym interfejsie, a w przypadku wdrożenia dla jednego użytkownika dotyczy to również aplikacji oraz API.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

Istnieje pułapka, w którą wpadają osoby zakładające, że firewall jest wystarczający. Publikacja portu kontenera za pomocą -p 3001:3001 powoduje, że Docker instaluje regułę DNAT. W rezultacie ruch jest obsługiwany w ścieżce FORWARD i nigdy nie przechodzi przez łańcuch INPUT, który podlega domyślnej polityce odmowy (deny) w ufw. Port pozostaje otwarty, mimo że ufw status nadal wyświetla Status: active. Powiąż opublikowany port z interfejsem loopback bezpośrednio w mapowaniu, używając zapisu -p 127.0.0.1:3001:3001, lub określ adres hosta w pliku compose. Weryfikację przeprowadzaj za pomocą ss -ltnp, a nie ufw status.

OpenBot nie jest rozwiązaniem typu offline

Uwzględnij to przed zaplanowaniem wdrożenia. OpenBot jest zależny od projektu CopilotKit Intelligence, który przechowuje trwałe wątki oraz historię konwersacji poza Twoim serwerem. Podczas uruchamiania serwer weryfikuje INTELLIGENCE_API_URL, INTELLIGENCE_GATEWAY_WS_URL, INTELLIGENCE_API_KEY oraz COPILOTKIT_LICENSE_TOKEN; wszystkie cztery parametry muszą być obecne, w przeciwnym razie proces startowy zakończy się niepowodzeniem. Według stanu na sierpień 2026 dostępny jest plan darmowy, a samą usługę Intelligence można hostować samodzielnie, więc pełne wdrożenie lokalne jest możliwe, choć wymaga więcej pracy niż zakłada quickstart.

Drugą zewnętrzną zależnością jest model. Pakiet nie zawiera żadnych gotowych modeli. BOT_PROVIDER akceptuje openai, anthropic lub google, a OPENAI_BASE_URL wskazuje ścieżkę OpenAI na dowolny kompatybilny punkt końcowy. W tym miejscu znajduje się uruchamianie Ollama na VPS w celu samodzielnego hostowania LLM, jeśli chcesz, aby tokeny pozostały na Twoim własnym sprzęcie. Sterowanie przeglądarką wymaga od modelu znacznych zasobów, dlatego przed podjęciem decyzji przetestuj model lokalny w rzeczywistym zadaniu.

Uruchomienie jednej repliki na obecnym etapie

Gateway przechowuje migawki stron w pamięci procesu serwera. Przy dwóch replikach migawka wykonana przez jeden proces jest niewidoczna dla drugiego, co powoduje sporadyczne błędy typu element-not-found, które wyglądają na losowe. Dokumentacja wdrożeniowa jest jednoznaczna: należy uruchomić pojedynczą replikę i ograniczyć maksymalną liczbę instancji platformy do 1. To ograniczenie przestanie obowiązywać, gdy buforowanie migawek zostanie przeniesione do bazy danych. Do tego czasu skalowanie OpenBot odbywa się poprzez zwiększenie zasobów maszyny, a nie dodawanie kolejnych jednostek. Izolacja między botami nadal jest zapewniana przez kontenery przypisane do poszczególnych botów, w taki sam sposób, w jaki piaskownice agentów self-hosted chronią przed skutkami błędów jednego agenta w odniesieniu do pozostałych.

Tryby awarii i ich objawy

Proces uruchamiania kończy się natychmiast po wypełnieniu .env. Serwer weryfikuje konfigurację przed rozpoczęciem obsługi jakichkolwiek żądań. Niekompletny blok Intelligence, brakujący KEY_ENCRYPTION_KEY lub dostawca OAuth z identyfikatorem klienta (client ID) bez klucza tajnego (secret) powodują zatrzymanie procesu zamiast cichej degradacji usługi. Należy odczytać pierwszy błąd, poprawić wskazane pole i uruchomić usługę ponownie.

Migracje kończą się niepowodzeniem w zarządzanej bazie danych. Rozszerzenie vector nie jest domyślnie włączone, przez co migracja odwołuje się do typu kolumny nieznanego w PostgreSQL. Należy połączyć się jako superużytkownik, wykonać CREATE EXTENSION vector;, a następnie ponownie uruchomić krok migracji.

Aplikacja ładuje się, ale logowanie nie jest utrzymywane. Usługa jest udostępniana przez zwykłe http:// na publicznym adresie, co nie stanowi bezpiecznego kontekstu, dlatego plik cookie Secure jest odrzucany. Należy wdrożyć TLS przed aplikacją lub użyć tunelu SSH, aby przeglądarka wykryła localhost.

Boty współdzielą loginy, które powinny być odrębne. Supervisor nie działa, więc nie ma izolacji komputerów dla poszczególnych botów i każdy z nich korzysta ze współdzielonej przeglądarki. Należy potwierdzić, że COMPUTER_SUPERVISOR_URL jest ustawione oraz że supervisor ma dostęp do gniazda Docker.

Bot zatrzymuje się i prosi o pomoc. Jest to zamierzone działanie systemu. Ścieżka audytu rejestruje computer.help_requested, użytkownik przejmuje kontrolę na ekranie na żywo, a przekazanie kontroli jest rejestrowane po obu stronach.

FAQ

Czy pozostawienie włączonej opcji OPENBOT_SINGLE_USER jest bezpieczne w przypadku wdrożenia na VPS?

Tylko wtedy, gdy brama nie jest dostępna z Internetu. OPENBOT_SINGLE_USER=true akceptuje każde żądanie jako administrator bez logowania, więc każdy, kto może otworzyć port, przejmuje kontrolę nad wdrożeniem, zapisanymi poświadczeniami oraz zalogowaną przeglądarką. Jest to dopuszczalne, gdy każdy port jest powiązany z 127.0.0.1, a dostęp do aplikacji odbywa się przez tunel SSH lub prywatny interfejs sieciowy. Na interfejsie publicznym należy wyłączyć tę opcję i skonfigurować Google, Microsoft Entra, Okta lub OIDC wraz z BETTER_AUTH_SECRET, BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS oraz TRUSTED_ORIGINS.

Ile pamięci RAM potrzebuje jeden bot OpenBot?

Opublikowane przez projekt dane dla pojedynczego bota na architekturze arm64 wskazują szczytowe zużycie pamięci na poziomie 0.55 GB, przy czym 2 GB jest udokumentowanym minimum, a 4 GB wartością zalecaną. Nie ma opublikowanych danych dla wielu botów jednocześnie, ponieważ każdy z nich utrzymuje własną instancję Chromium. Należy uruchomić jednego bota w rzeczywistym zadaniu, odczytać zużycie pamięci kontenera w docker stats, dodać zużycie bramy i bazy danych, a następnie pomnożyć wynik przez liczbę botów, które mają działać jednocześnie.

Czy do samodzielnego hostowania OpenBot potrzebne jest konto CopilotKit?

Tak. OpenBot polega na projekcie CopilotKit Intelligence w zakresie trwałych wątków i pamięci, a serwer odmawia uruchomienia, jeśli adres URL Intelligence API, adres URL WebSocket bramy, klucz API oraz token licencyjny nie są ustawione. Plan darmowy jest dostępny od sierpnia 2026 roku, a usługę Intelligence można hostować samodzielnie, więc zależność od hostowanej usługi można usunąć przy dodatkowym nakładzie pracy. Należy również dostarczyć własny klucz API modelu, ponieważ żaden model nie jest dostarczany wraz z OpenBot.

Dlaczego każdy bot otrzymuje własną przeglądarkę zamiast współdzielić jedną?

Ponieważ profil przeglądarki stanowi tożsamość. Współdzielona przeglądarka oznacza współdzielone pliki cookie i sesje, więc jeden bot zalogowany na konto powoduje, że każdy bot jest zalogowany na to samo konto. Kontenery przypisane do poszczególnych botów zapewniają każdemu z nich własny profil i własne dane logowania. Kosztem jest pamięć, ponieważ instancja Chromium na bota jest największym pojedynczym elementem wpływającym na zapotrzebowanie na zasoby.

Które porty OpenBot powinny być otwarte na zaporze sieciowej?

Żaden z portów niskiego poziomu. Agent-computer na 4100, punkty końcowe botów na 4200 i 4201, supervisor na 4500 oraz PostgreSQL na 5432 powinny pozostać prywatne. Projekt zabezpiecza je tokenami i zaleca, aby w każdym przypadku pozostały niedostępne z zewnątrz. Należy publikować tylko to, co jest niezbędne dla użytkownika, pamiętając, że port kontenera opublikowany za pomocą -p 3001:3001 jest dostępny niezależnie od reguły ufw default-deny, ponieważ reguła DNAT w Dockerze kieruje ten ruch ścieżką FORWARD zamiast INPUT.