Rakazo: self-hosted persistent AI teammates with bring-your-own model and sandbox

What Rakazo actually solves for a self-hoster

Most chat assistants forget. You close the tab, the context is gone, and the next session starts from nothing. Rakazo is built around the opposite assumption: a bot is a persistent entity with its own conversations, memory, routines and history, and it keeps running when your laptop is closed. The README describes it as an open-source platform for running persistent AI teammates, available on the web, as an Electron desktop app, and through an Expo mobile app. The intended user is someone who wants that persistence without handing over model credentials or the machine the bot operates on. Rakazo lets you bring your own model credentials through Pi, and it supports Docker, E2B, Daytona, Box and a trusted local computer as execution environments. That combination is the point: the model and the sandbox are both swappable, so you are not buying a bundled inference plan. The project is in beta and the repository says so plainly, which matters more than any feature list.

The architecture visible in the README

The stack is TypeScript throughout: React 19, Vite and Tailwind on the front end, Electron and Expo for the two native clients, Hono and oRPC for the API layer, PostgreSQL with Prisma for state, Better Auth for accounts, and Graphile Worker for background jobs. The README states that the Electron and Expo apps are clients of the same Rakazo API used by the web app, so there is one backend and three front ends rather than three products. Bots can delegate to peer bots or to short-lived subagents, which suggests a supervisor pattern rather than a single flat loop. Tool access comes from several directions: Composio or Pipedream Connect for managed app catalogs, plus user-installed Treg, remote MCP servers, and OpenAPI tool sources. Connector credentials are encrypted on the server and, per the README, are never returned by the API. Execution happens on either shared Team Computers or isolated Private computers, with browser, terminal, file and graphical desktop access. The split between shared and private computers is the most consequential design decision in the whole system, and the README does not explain the isolation boundary in detail.

Installing from published images without a source checkout

The quickest path needs Docker Engine, the Compose plugin, curl and OpenSSL. No clone, no Node install. The README gives this sequence: create a directory, download infra/compose/install-images.sh from the repository, and run it with bash. The installer downloads the Compose files, creates a .env with random secrets, and starts Rakazo, and it preserves an existing .env when rerun. The default image tag is edge, built from main for linux/amd64 and linux/arm64. After that you open http://127.0.0.1:5173, create an account, and connect a model. Local Docker computers are on by default; remote providers e2b, daytona or box each need the matching API key. On restricted networks the installer accepts RAKAZO_DOWNLOAD_BASE to override the download base, and --local or RAKAZO_DOWNLOAD_SKIP_EXISTING to skip existing Compose files. There is also a SETUP_PROMPT.md for an agent-assisted install.

Running it on a server and the config keys that matter

Bots stay on when the backend runs on a server, which is the configuration most people actually want. The README's server flow is to run the same installer with --prepare-only, edit .env to set SANDBOX_PROVIDER to box, e2b or daytona with its API key and RAKAZO_HOST to your domain, then run the installer again. HTTPS belongs in front of port 5173, and the self-hosting guide covers Caddy and host hardening. In the desktop app you then choose Existing instance and enter the https address. A source checkout is a different job. It requires Node.js 22.22.2 or newer in the 22.x line, Node.js 24.x, or Node.js 26 or later; 23.x and 25.x are explicitly unsupported. You also need pnpm 9 and Docker. After copying .env.example you set POSTGRES_PASSWORD and mirror it in DATABASE_URL, then set BETTER_AUTH_SECRET, ENCRYPTION_KEY, SCREEN_PROXY_SECRET and, for Docker sandboxes, SANDBOX_SUPERVISOR_TOKEN, each to independent random values. Then pnpm install, pnpm db:generate, pnpm db:migrate, pnpm sandbox:build and pnpm dev. Note the volume behaviour: an existing pgdata volume keeps the user, password and database from first init, so changing POSTGRES_PASSWORD in .env after the fact will not take effect, and docker compose down -v deletes all Postgres state.

Where Rakazo is the wrong tool

The beta label is not decoration. Three releases landed between 7 September and 8 September 2026 (v0.1.4, v0.1.5, v0.1.6), which is a normal cadence for a project still finding its shape and a poor fit for anyone who needs a frozen API surface. If you are building a product on top of Rakazo's oRPC layer rather than using its UI, treat every minor version as potentially breaking until the project says otherwise. The second limitation is operational: persistence is the selling point, and persistence means a server that stays up. The README's server path assumes a VPS, a domain, HTTPS termination and a sandbox provider key. That is a real bill and a real maintenance surface, and the desktop app's This computer mode only moves the problem into Docker Desktop or OrbStack on your own machine. Third, Treg is usage-metered. Self-hosters supply their own Treg token, and the README points operators embedding Treg in a hosted product at Treg's integration terms, which require a written agreement for hosted resale. If you planned to resell access to a hosted Rakazo instance, that constraint applies before you write any code. Finally, the README does not document the isolation boundary between shared Team Computers and Private computers, so if your threat model depends on that boundary you have to read the source or the self-hosting guide rather than the front page.

How it differs from running an agent framework directly

The obvious alternative is assembling the same thing from an agent framework plus a sandbox API plus a scheduler, and that comparison is worth taking seriously because Rakazo is essentially a pre-assembled version of it. The difference in approach is where the state lives. A framework-based build typically treats a run as a function call: you construct the context, execute, and persist whatever you decide to persist. Rakazo inverts that. The bot is the durable object, with its own conversations, memory and routines, and the runs are events inside it. That is why the stack includes Graphile Worker for background jobs and Prisma over PostgreSQL rather than a queue and a blob store. It is also why the sandbox is a first-class concept with named providers instead of a library you import. The trade-off is control. A hand-built stack lets you define the isolation model, the memory schema and the tool permission system exactly. Rakazo gives you its versions of all three and asks you to accept the Composio, Pipedream, Treg, MCP and OpenAPI integration surface as it stands. If your requirements sit inside what Rakazo already supports, assembling it yourself is duplicated work. If they sit outside, Rakazo will fight you.

Maintenance cost, upgrades and licence terms

Rakazo is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes. That is the standard permissive position and it is the reason a hosted product on top of Rakazo is legally straightforward, with one exception already noted: Treg's own integration terms sit outside the Apache grant and require a written agreement for hosted resale. Rakazo's licence does not cover Treg's service. Upgrade cost depends on which install you chose. The published-image path pins the default tag to edge, which tracks main builds, so an unpinned install follows whatever landed most recently. Installed desktop builds pin the image tag to their own version, and unpackaged builds pull edge. For a server, pinning a specific tag rather than following edge is the difference between a controlled upgrade and an uncontrolled one. The source-checkout path adds database migrations to every upgrade, and the README warns that the pgdata volume retains first-init credentials, so a restore or a credential rotation is a deliberate operation rather than a config edit. There is no documented migration tooling beyond pnpm db:migrate, and no stated support window for older releases. Budget for reading release notes before every bump.

Editorial conclusion

Adopt Rakazo if you want a bot that keeps its own conversation history, memory and routines on hardware you control, and you are willing to run Docker plus Postgres and pick a sandbox provider. Do not adopt it if you need a stable API contract, because the project is in beta and shipped three patch releases in four days. Before committing, verify that your model provider is reachable through Pi, that your chosen sandbox provider has a working key, and that your Node.js version is 22.22.2 or newer in the 22.x line, 24.x, or 26 or later.

Official sources

1. elie222/rakazo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases