Własny zespół botów AI.
Na Twoim serwerze.

Objaw: rejestracja przechodzi, ale zamiast panelu widzisz prośbę o kliknięcie w link wysłany na e-mail. Mail nie przychodzi. W spamie też go nie ma, bo nigdy nie wyszedł.

Przyczyna: w .env jest wpisana lista dozwolonych adresów (SIGNUP_ALLOWLIST). Wygląda to na rozsądne zabezpieczenie - wpuszczam tylko siebie - ale w aktualnej wersji Rakazo niepusta lista włącza jednocześnie wymóg potwierdzenia adresu mailem. Instalacja z tego poradnika nie ma skonfigurowanej poczty wychodzącej, więc czekasz na link, którego nikt nie wysłał.

Co robisz: czyścisz listę, restartujesz trzy usługi i rejestrujesz się jeszcze raz - a zaraz potem zamykasz rejestrację, tak jak w Kroku 3.

cd ~/rakazo
sed -i "s|^SIGNUP_ALLOWLIST=.*|SIGNUP_ALLOWLIST=|" .env
docker compose --env-file .env -f docker-compose.images.yml up -d api worker web

Komunikat nie znika? Polityka rejestracji zapisała się w bazie przy pierwszym starcie i plik .env przestał rządzić. Wyczyść ją bezpośrednio w bazie:

cd ~/rakazo
docker exec rakazo-postgres-1 psql -U rakazo -d rakazo -c "update deployment_settings set \"signupAllowlist\"='' where id='default';"

Bezpieczeństwo bierze się tutaj nie z listy adresów, tylko z tego, że rejestracja jest otwarta przez kilka minut i wyłączona na stałe zaraz po tym, jak założysz konto.

Objaw: podpinasz Composio (to przez niego bot dostaje dostęp do GitHuba, YouTube'a i reszty), klucz wygląda dobrze, a połączenie i tak jest odrzucane.

Przyczyna: Composio ma dwa rodzaje kluczy i wyglądają niemal identycznie. Rakazo potrzebuje klucza zaczynającego się od ak_ - tego z trybu PLATFORM. Klucz zaczynający się od ck_ jest z innego trybu i nie zadziała, niezależnie od tego, ile razy go wkleisz.

Co robisz: wróć do panelu Composio, przełącz się na tryb PLATFORM (przełącznik "Switch" w panelu, potem projekt → API keys → Create API key) i wygeneruj klucz stamtąd. Sprawdzenie zajmuje sekundę - patrzysz na dwa pierwsze znaki. Klucz wklejasz w Rakazo w zakładce Integrations (źródło Composio → API key → Connect), nie w czacie z agentem.

Objaw: zlecasz botowi zadanie, a on przy pierwszej poważniejszej czynności staje i prosi o potwierdzenie. Potem przy następnej. I następnej. Rutyna o 07:00 rano nie robi nic, bo nikt nie kliknął "zgoda".

Przyczyna: Rakazo ma automatycznego recenzenta, który ocenia, czy dana czynność jest bezpieczna. Domyślnie daje mu na to 1,5 sekundy. Żaden model się w tym nie mieści, więc recenzent milczy, a decyzja spada na człowieka.

Co robisz: wskaż recenzentowi szybki model i daj mu sensowny czas. Trzy linijki w pliku .env, potem restart stacku:

RAKAZO_AUTO_REVIEW_PROVIDER=openrouter
RAKAZO_AUTO_REVIEW_MODEL=google/gemini-3.1-flash-lite
RAKAZO_AUTO_REVIEW_TIMEOUT_MS=30000

Od tej pory szybki i tani model ocenia czynności w tle, a Ciebie bot pyta tylko wtedy, gdy naprawdę jest o co pytać.

Objaw: kontener komputera się wywalił albo serwer został zrestartowany w trakcie pracy bota. Po ponownym starcie pulpit jest, ale Chromium nie rusza.

Przyczyna: Chromium zostawia w profilu plik-blokadę, żeby dwie kopie nie pisały po tych samych danych. Przy czystym zamknięciu sam go sprząta. Przy nagłym padzie plik zostaje i blokuje kolejne uruchomienie.

Co robisz: usuwasz blokadę w katalogu domowym komputera bota i uruchamiasz go ponownie:

rm -f "$HOME/.browser-profiles/chromium/SingletonLock" \
      "$HOME/.browser-profiles/chromium/SingletonCookie" \
      "$HOME/.browser-profiles/chromium/SingletonSocket"

Nic nie tracisz - to są pliki tymczasowe, nie Twoje zalogowane sesje.

Objaw: pulpit bota jest czarny albo widzisz, że ekran przejęła nowsza sesja. W menu komputera świeci „Computer is busy", a Recover computer i Reset computer odpowiadają tym samym komunikatem. Zadanie bota dawno się skończyło.

Przyczyna A (najczęstsza): to Ty trzymasz sterowanie. Po „Take control" Twoja karta przedłuża dzierżawę co kilkadziesiąt sekund, a Recover i Reset odmawiają, dopóki ktoś trzyma mysz i klawiaturę. Czarny obraz to uchwyt ekranu z poprzedniej sesji podglądu. Przyczyna B (bug Rakazo, stan na wrzesień 2026): po „Take control" instalacja zakłada dzierżawę komputera na 24 godziny i nie zwalnia jej po zakończeniu zadania bota. Poprawka jest zgłoszona do autorów.

Co robisz: wyłącz „Take control" albo zamknij panel ekranu i odczekaj minutę, przeładuj stronę i kliknij Open computer - w wariancie A to zwykle wystarcza. Nadal czarno? Teraz Recover computer przejdzie. Dalej „busy"? Upewnij się, że bot nie ma naprawdę trwającego zadania (Stop w wątku), potem skrypt z repo, scripts/unlock-computer.sh, uruchomiony na serwerze - pokazuje dzierżawy, pyta o zgodę, usuwa tylko te po zakończonych zadaniach i zeruje zawieszone sterowanie. Ostateczność, gdy ekran dalej czarny: docker stop kontenera komputera bota, supervisor postawi nowy przy następnym użyciu. Pliki bota w shared/ zostają. Agent w wizardzie ma tę procedurę w Fazie 7.

Objaw: liczysz kontenery i wychodzi pięć, a instrukcja mówi o siedmiu. Pierwsza myśl: coś się nie uruchomiło.

Przyczyna: dwa z nich to zadania jednorazowe - jedno pobiera obraz pulpitu, drugie ustawia właściciela katalogu z danymi. Kończą się poprawnie i przechodzą w stan zakończony, a lista domyślnie pokazuje tylko to, co aktualnie działa.

Co robisz: dopisujesz -a. Pięć linii zamiast siedmiu to poprawny wynik, nie brak.

cd ~/rakazo
docker compose --env-file .env -f docker-compose.images.yml ps -a

Objaw: instalator wisi kilka minut bez widocznego postępu. Kusi, żeby przerwać i spróbować jeszcze raz.

Przyczyna: ściąga 6,8 GB obrazów. Na łączu hostingu schodzi to w 2-3 minuty, na wolniejszym w kwadrans. To nie jest zawieszenie, to po prostu duży plik.

Co robisz: z drugiego terminala patrzysz, czy coś przybywa. Jeśli po kwadransie nadal cisza - przerywasz i powtarzasz instalator. Zachowa istniejący .env i dociągnie tylko brakujące warstwy.

docker images | grep rakazo
df -h /

Objaw: instalacja pakietu stoi, a w logu przewijają się komunikaty o niemożności otwarcia okna konfiguracyjnego. Nic się nie dzieje ani przez minutę, ani przez pięć.

Przyczyna: pakiet chce zadać pytanie w okienku, którego w sesji SSH nie ma. Czeka na odpowiedź, której nigdy nie dostanie, i po drodze blokuje mechanizm instalacji pakietów dla wszystkiego innego.

Co robisz: ubijasz zawieszony proces, porządkujesz to, co zostało w połowie, i powtarzasz instalację z przedrostkiem, który mówi „nie zadawaj pytań".

sudo pkill -f apt-get
sudo dpkg --configure -a --force-confdef --force-confold
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y NAZWA_PAKIETU

Ten przedrostek dawaj przy każdej instalacji pakietów, nie tylko przy naprawie. Wizard robi to za Ciebie.

Objaw: przy komputerze bota wisi informacja o dostępnej aktualizacji. Klikasz, coś się dzieje, komunikat wraca.

Przyczyna: w wersjach do początku września to pole było zapalone praktycznie zawsze, niezależnie od stanu obrazu - czyli był to szum, nie sygnał. W nowszych wersjach zastąpiło je pole opisujące, czy aktualizacja jest w ogóle możliwa, i wtedy komunikat już coś znaczy.

Co robisz: na starszym obrazie po prostu ignorujesz. Na nowszym pamiętaj, że odświeżenie komputera bota tworzy kontener od nowa - katalog domowy jest zapisywany i przywracany, ale to nie jest operacja za darmo. Nie klikaj tego w oknie, w którym mają się odpalić rutyny.

Objaw: rutyna albo zlecone zadanie zostało w stanie „w trakcie", a w wątku nic nie przybywa.

Przyczyna: usługa wykonująca zadania została zrestartowana w trakcie pracy. Zadanie zostaje wtedy osierocone - nikt go już nie dokończy, bo ten, kto je prowadził, przestał istnieć.

Co robisz: zaglądasz w logi, żeby się upewnić, i odpalasz rutynę ponownie przyciskiem Run now. Na przyszłość: restartuj usługi wtedy, gdy nic nie leci, a nie w środku okna rutyn.

docker logs rakazo-worker-1 --tail 60

Objaw: Open computer otwiera panel, obraz jest czarny, nic nie mówi, że coś jest nie tak. W kontenerze bota przeglądarka żyje. W logu Caddy (sudo journalctl -u caddy -n 50) wpisy 502 / EOF dla GET /novnc/session/..., w których /novnc/session/ występuje dwa razy w jednym adresie.

Przyczyna: bug Rakazo od 8 września 2026 (zmiana „Revoke screen capabilities", #822, zgłoszenie #832). Strona ekranu składa adres WebSocketu z katalogu strony i parametru path, a od tej zmiany parametr sam zawiera pełny prefiks. Prefiks się dubluje, websockify dostaje nieistniejącą ścieżkę i zrywa połączenie. Instalacje sprzed 8 września tego nie mają - dlatego na produkcji z filmu działa, a na świeżej nie.

Co robisz: jedna linia w /etc/caddy/Caddyfile, w bloku domeny, przed reverse_proxy:

uri path_regexp ^(/novnc/session/(?:view|control)/[^/]+)/novnc/session/(?:view|control)/[^/]+(/.*)$ $1$2

Potem sudo systemctl reload caddy, przeładowanie panelu i Open computer. Wizard wpisuje tę linię sam w fazie F4. Po poprawce w upstreamie linia jest nieszkodliwa.

Objaw: komputer bota znika w połowie pracy. W logach nie ma żadnego sensownego wyjaśnienia - po prostu koniec.

Przyczyna: komputer bota ma twardy sufit pamięci, domyślnie 2 GB. Pulpit, menedżer okien i przeglądarka z kilkoma kartami potrafią go przekroczyć, a wtedy system ubija kontener bez ostrzeżenia.

Co robisz: na serwerze 8 GB podnosisz sufit do 4 GB. Na 4 GB raczej odciążasz bota - jedno zadanie naraz, mniej kart - bo 4 GB dla komputera nie zmieści się obok reszty.

cd ~/rakazo
grep -q '^RAKAZO_COMPUTER_MEMORY=' .env \
  && sed -i "s|^RAKAZO_COMPUTER_MEMORY=.*|RAKAZO_COMPUTER_MEMORY=4g|" .env \
  || echo 'RAKAZO_COMPUTER_MEMORY=4g' >> .env
docker compose --env-file .env -f docker-compose.images.yml up -d supervisor

Format to 4g albo 1536m. Wpisanie 4GB wywali usługę przy starcie i zablokuje całe uruchomienie.