elie222/rakazo

The problem

Hosted agent products give you a capable assistant but keep the model choice, the compute, the memory and the integrations on their side. If you want a bot that keeps state across conversations, runs routines on a schedule, and can actually use a browser or terminal without handing your credentials to a vendor, you end up stitching together an agent loop, a sandbox provider, a scheduler and a UI yourself. Rakazo packages that whole stack into one deployable system with web, Electron and mobile clients.

What's different

The usual approach is either a framework you assemble (LangGraph-style orchestration, or a bare SDK) or a closed hosted agent. Rakazo sits in the middle: it ships the runtime plus the surface. The distinctions that actually matter are persistent per-bot state (conversations, memory, routines) rather than one-off sessions; pluggable sandbox backends including local Docker, E2B, Daytona, CreateOS, Boat and Railway, with a distinction between shared team computers and private ones; and bring-your-own model credentials so inference is not tied to the vendor. Bot-to-bot delegation and short-lived subagents are also part of the design. What it does not appear to offer is a heavily opinionated evaluation or observability layer — the README does not describe one.

Who it's for

Developers and small teams who are comfortable running Postgres and Docker and who want agent capability with self-hosting as a first-class option — particularly those who care about which model provider is used and where tool execution happens. It is also reasonable for someone who wants a Grok Bot-like experience on their own VPS with mobile access. Look elsewhere if you need a stable, documented enterprise platform: the project labels itself beta, and anyone who just wants a chat client should use a hosted product instead.

Cost of adoption

Requirements are non-trivial: Docker Engine and Compose, or Node 22/24/26 with pnpm 9 for source builds, plus Postgres, and several secrets (auth secret, encryption key, screen proxy secret, and a sandbox supervisor token for Docker sandboxes). The published-image path avoids a checkout — the README's installer is a single curl script that writes .env and starts the stack. Optional providers (Composio, Pipedream, Treg, E2B, Daytona, Railway) are metered and need their own keys. The README explicitly flags Treg's usage metering and terms for hosted resale, which matters if you plan to embed this in a product. Apache-2.0 is permissive. The main risk is maturity: a long configuration surface and a beta label.

Verdict

The repository is young — about 72 days old — and its 5,573 stars arrived fast, with a strong monthly board showing (+2,518 this month, #12 in TypeScript) despite never hitting the daily board. That pattern says a launch spike rather than sustained organic adoption, and there is no Hacker News discussion to corroborate traction. The scope is genuinely ambitious and the architecture choices are sensible, but at this age the code has not survived a long maintenance cycle. Treat it as a promising project to pilot, not one to build a product on yet.