Rakazo: alternatywa dla GrokBota
← Wszystkie wpisy

Rakazo: open-source alternatywa dla GrokBota

Rakazo to open-source, self-hosted alternatywa dla GrokBota: autonomiczni agenci AI we własnej infrastrukturze, wybór modelu LLM i pełna kontrola nad danymi.


GrokBot stał się w ostatnich tygodniach jednym z głośniejszych tematów w społecznościach AI i DevOps. Autonomiczny agent xAI, zdolny do wykonywania złożonych zadań w przeglądarce, obsługi skrzynek mailowych czy pracy z kodem, szybko zwrócił uwagę użytkowników zainteresowanych automatyzacją. Jednocześnie zamknięta infrastruktura oznacza ograniczoną kontrolę nad środowiskiem, w którym autonomiczny agent działa i przetwarza dane.

W tym samym czasie Elie Steinbock, znany wcześniej z projektu Inbox Zero, opublikował na GitHubie Rakazo, projekt open source realizujący podobną koncepcję. Każdy bot otrzymuje własny wątek, piaskownicę, pamięć i harmonogram, natomiast infrastruktura może działać po stronie użytkownika. Projekt powstał przy użyciu Cursor i Grok 4.6, co autor podaje w README, i został udostępniony na licencji Apache 2.0.

Rakazo jest jeszcze na wczesnym etapie rozwoju, ale już teraz można sprawdzić, jak wygląda jego architektura, czego wymaga instalacja i gdzie kończą się możliwości obecnej wersji.

Czym jest Rakazo

Rakazo to platforma do uruchamiania autonomicznych agentów AI w izolowanych środowiskach. Każda instancja bota otrzymuje jeden wątek konwersacji, dedykowaną piaskownicę (sandboxed Linux desktop z przeglądarką), pamięć między sesjami oraz system rutyn. Rutyny są instrukcjami zapisanymi w plikach Markdown, które bot może wykonywać samodzielnie lub na żądanie.

W porównaniu z GrokBotem podstawowa różnica dotyczy kontroli nad środowiskiem. Rakazo może działać na własnym serwerze i nie wymusza korzystania z infrastruktury xAI. Nie ogranicza też użytkownika do Groka: architektura projektu pozwala korzystać z innych modeli językowych, między innymi za pośrednictwem OpenRouter.

Projekt działa jako monorepo z pięcioma głównymi aplikacjami: interfejsem webowym, API, workerem, aplikacją desktopową opartą na Electronie oraz aplikacją mobilną wykorzystującą React Native i Expo. Wszystkie korzystają z tego samego backendu, dzięki czemu rozpoczęte zadanie można obsługiwać z różnych klientów.

Stack technologiczny opiera się głównie na ekosystemie Node.js: TypeScript, Node.js 22+, PostgreSQL, Prisma ORM, Docker do izolacji piaskownic, Vite jako frontend i pnpm 9 do zarządzania pakietami w monorepo.

GrokBot a Rakazo: szybkie zestawienie

Oba projekty opierają się na podobnym założeniu: agent otrzymuje dostęp do systemu, przeglądarki i zewnętrznych usług, dzięki czemu może wykonywać zadania wykraczające poza zwykłą rozmowę z modelem. Różnica zaczyna się tam, gdzie pojawiają się kwestie hostingu, kontroli nad danymi i wyboru modelu.

  • Hosting. GrokBot działa w infrastrukturze zarządzanej przez xAI, Rakazo jest self-hosted.
  • Model LLM. GrokBot korzysta z Groka, Rakazo pozwala wybrać model przez OpenRouter albo Pi.
  • Koszt. GrokBot wymaga abonamentu, Rakazo nie nakłada opłat licencyjnych.
  • Dane. W GrokBocie trafiają do dostawcy, w Rakazo zostają lokalnie albo na własnym serwerze.
  • Kod. GrokBot jest zamknięty, Rakazo jest open source na licencji Apache 2.0.

Brak opłat licencyjnych nie oznacza oczywiście, że Rakazo działa bez kosztów. Pozostają zasoby potrzebne do utrzymania infrastruktury oraz opłaty za wybrany model lub zewnętrzne usługi. W zamian użytkownik otrzymuje jednak większą kontrolę nad sposobem wdrożenia.

Instalacja

Do uruchomienia Rakazo potrzebny jest Node.js w wersji 22 lub nowszej, pnpm 9 oraz Docker Desktop albo Docker Engine na Linuksie. Klucz API OpenRouter nie jest wymagany podczas początkowej konfiguracji, można podać go później w interfejsie webowym.

Klonowanie repozytorium i konfiguracja środowiska

# Klonowanie repozytorium
git clone https://github.com/elie222/rakazo.git
cd rakazo

# Skopiuj plik konfiguracyjny i uzupełnij wartości
cp .env.example .env

W pliku .env należy ustawić wymagane zmienne BETTER_AUTH_SECRET oraz ENCRYPTION_KEY. Mogą to być odpowiednio długie, losowe ciągi znaków. Opcjonalnie można dodać OPENROUTER_API_KEY do obsługi modeli LLM oraz COMPOSIO_API_KEY, jeśli planujemy korzystać z integracji z zewnętrznymi aplikacjami.

Baza danych i zależności

# Uruchom PostgreSQL przez Docker
docker compose -f infra/compose/docker-compose.yml up postgres -d

# Zainstaluj zależności wszystkich pakietów w monorepo
pnpm install

Migracje i uruchomienie

# Wygeneruj klienta Prisma i uruchom migracje
pnpm db:generate
pnpm db:migrate

# Zbuduj obraz Docker dla piaskownic botów
pnpm sandbox:build

# Uruchom wszystkie aplikacje w trybie deweloperskim
pnpm dev

Po uruchomieniu interfejs webowy powinien być dostępny pod adresem http://127.0.0.1:5173.

Opcje piaskownic

Jednym z ciekawszych elementów Rakazo jest możliwość wyboru środowiska izolowanego za pomocą zmiennej SANDBOX_PROVIDER. Dostępne warianty odpowiadają różnym scenariuszom:

  • docker (domyślny). Kontener lokalnie, jeden na bota. Lokalna instalacja i szybki start.
  • e2b. Sandbox E2B jako SaaS. Wdrożenia wieloużytkownikowe, silniejsza izolacja.
  • desktop. Bezpośrednio na hoście. Single-user i testy.
  • fake. Emulator in-process. Testy jednostkowe.

Szczególnej uwagi wymaga tryb desktop. Nie powinien być używany na publicznym serwerze: polecenia generowane przez model są w tym przypadku wykonywane z uprawnieniami procesu Rakazo, więc agent uzyskuje znacznie bardziej bezpośredni dostęp do systemu. Autor projektu sam wskazuje to ograniczenie w dokumentacji.

W przypadku autonomicznego agenta nie jest to detal implementacyjny. Sposób izolacji środowiska decyduje o tym, jakie skutki może mieć błędna decyzja modelu albo nieprzewidziane działanie wykonywanego polecenia, ten sam problem opisuję szerzej przy zasadzie minimalnych uprawnień dla agentów AI.

Mocne strony

Największą zaletą Rakazo jest kontrola nad infrastrukturą i danymi. Projekt można uruchomić na własnym serwerze, a sposób izolowania poszczególnych agentów dostosować do scenariusza wdrożenia. Dla osób korzystających już z Dockera i własnej infrastruktury wejście w projekt nie powinno być szczególnie trudne.

Istotna jest też swoboda wyboru modelu LLM przez Pi lub OpenRouter. Rakazo nie wiąże całej platformy z jednym dostawcą modelu, co ułatwia eksperymentowanie z różnymi konfiguracjami i pozwala zmienić backend bez wymiany całego systemu agentowego.

Rutyny zapisane w Markdown są prostym rozwiązaniem, ale dobrze pasują do środowiska deweloperskiego. Można je czytać, modyfikować i wersjonować w Git bez dodatkowych narzędzi. Projekt oferuje również klientów webowych, desktopowych i mobilnych oraz integrację z Composio.

Kod został opublikowany na licencji Apache 2.0, a repozytorium jest regularnie rozwijane. Przy projekcie znajdującym się na tak wczesnym etapie jest to dobry sygnał, choć sama częstotliwość commitów nie mówi jeszcze wiele o jego długoterminowej stabilności.

Słabe strony

Rakazo pozostaje projektem we wczesnej fazie beta. Wersja 0.1.0-beta została opublikowana 13 sierpnia 2026 roku, dlatego trudno oczekiwać dojrzałości porównywalnej z platformami rozwijanymi od kilku lat.

Jednym z ograniczeń jest brak obsługi Claude Pro przez interfejs użytkownika przy lokalnym uruchomieniu, związany z callbackiem kierowanym na localhost. Historia wątku może również rosnąć bez ograniczeń: w repozytorium zgłoszono brak mechanizmu kompresji kontekstu.

Większym problemem z punktu widzenia zastosowań produkcyjnych jest brak mechanizmu zatwierdzania działań potencjalnie destrukcyjnych. Agent, który może wysyłać wiadomości, korzystać z zewnętrznych usług czy wykonywać operacje powodujące koszty, powinien mieć możliwość zatrzymania się przed takim działaniem i poproszenia użytkownika o zgodę, dokładnie tak jak opisuję to przy nadzorze człowieka nad działaniami wysokiego ryzyka. Taki mechanizm znajduje się wśród postulatów zgłaszanych w repozytorium.

Opcja Cloud pozostaje na liście oczekujących, więc obecnie trzeba przygotować własną infrastrukturę. Nie musi być to wadą dla użytkownika zainteresowanego self-hostingiem, ale ogranicza dostępność projektu dla osób oczekujących gotowej usługi.

Do tego dochodzi niestabilne API oraz możliwość ręcznej interwencji przy migracjach bazy. Przy dynamicznie rozwijającym się projekcie nie jest to szczególnie zaskakujące, ale ma znaczenie, jeśli ktoś rozważa Rakazo jako element środowiska produkcyjnego.

Ciekawy kierunek, ale nie na produkcję

Rakazo odpowiada na konkretne potrzeby osób, dla których prywatność danych, własna infrastruktura i możliwość wyboru modelu mają większe znaczenie niż wygoda gotowej usługi. Jeśli szukasz self-hostowanej alternatywy dla GrokBota, jest to jeden z projektów, którym warto się przyjrzeć.

Trzeba jednak traktować go zgodnie z obecnym etapem rozwoju. To wciąż beta, z ograniczeniami, które utrudniają wykorzystanie Rakazo w krytycznych procesach biznesowych. Brak kompresji kontekstu, problemy z częścią integracji i przede wszystkim brak mechanizmu zatwierdzania ryzykownych operacji mają większe znaczenie niż brak kilku funkcji w interfejsie.

Dla deweloperów, inżynierów bezpieczeństwa i osób zainteresowanych self-hostingiem Rakazo jest przede wszystkim projektem wartym obserwowania i testowania w kontrolowanym środowisku. Architektura pokazuje interesujący kierunek rozwoju agentów AI: zamiast kolejnej zamkniętej usługi dostajemy system, który można uruchomić, przeanalizować i dostosować na własnej infrastrukturze. Kod źródłowy jest dostępny na GitHubie.

Źródła

  1. Repozytorium GitHub, Elie Steinbock, „rakazo”
  2. Ogłoszenie autora na X
  3. AgentRiot, „Rakazo: Open-Source Grok Bot Alternative”
  4. OpenAlternative, wpis o Rakazo
  5. EveryDev, wpis o Rakazo