Rakazo : des bots persistants que vous hébergez, avec le modèle et le bac à sable de votre choix

Le problème visé : des bots qui gardent leur contexte et leurs droits

Un assistant IA classique repart de zéro à chaque conversation. Rakazo prend le parti inverse : le README parle de bots persistants dotés de leurs propres conversations, mémoire, routines et historique. La persistance est donc le cœur du produit, pas une option ajoutée après coup. Le second axe est la propriété de l'exécution : le projet se présente comme une alternative open source à Grok Bot où l'on choisit son modèle et son bac à sable. Le public visé est technique. Il faut savoir lire un fichier .env, lancer Docker Compose et générer des secrets. Le README mentionne aussi un mode vocal, des ordinateurs d'équipe partagés et des ordinateurs privés isolés, l'accès navigateur, terminal, fichiers et bureau graphique, la délégation entre bots et vers des sous-agents éphémères. C'est une plateforme, pas un script. Les intégrations passent par Composio ou Pipedream Connect, plus des sources d'outils installées par l'utilisateur : serveur MCP distant, point de terminaison Treg, document OpenAPI JSON.

Une pile TypeScript, un backend unique pour trois clients

La pile annoncée est cohérente : TypeScript, React 19 avec Vite et Tailwind, Hono et oRPC côté API, PostgreSQL avec Prisma, Better Auth pour l'authentification, Graphile Worker pour les tâches. Les applications Electron et Expo ne sont pas des implémentations séparées : le README précise qu'elles sont clientes de la même API que l'application web. Cette architecture évite de dupliquer la logique métier, mais elle implique qu'un serveur doit rester joignable pour que les bots continuent de tourner. C'est exactement ce que décrit la section serveur : les bots restent actifs quand le backend est hébergé sur une machine distante, et l'on s'y connecte depuis le bureau, le mobile ou un navigateur. Le fournisseur de modèles est apporté par l'utilisateur via Pi, ce qui veut dire que Rakazo ne revend pas d'inférence : vous branchez vos propres identifiants. Les bacs à sable reposent sur Docker, E2B, Daytona ou Box, avec un mode ordinateur local de confiance. Le choix du fournisseur de bac à sable est donc un paramètre de déploiement, pas une constante du code.

Installation par images publiées : trois commandes et un .env

La voie la plus courte ne demande ni clone ni Node. Il faut Docker Engine, le plugin Compose, curl et OpenSSL. Le README donne la séquence : créer un dossier rakazo, y télécharger install-images.sh depuis le dépôt, puis l'exécuter avec bash. Le script récupère les fichiers Compose, crée un .env avec des secrets aléatoires et démarre Rakazo ; il préserve un .env existant en cas de réexécution. L'interface s'ouvre ensuite sur 127.0.0.1:5173, où l'on crée un compte et connecte un modèle. Les ordinateurs Docker locaux sont activés par défaut, et l'on peut ajouter e2b, daytona ou box avec la clé API correspondante. Le tag d'image par défaut est edge, construit depuis main pour linux/amd64 et linux/arm64. Sur un réseau restreint, le README indique trois leviers : RAKAZO_DOWNLOAD_BASE pour changer la base de téléchargement, --local ou RAKAZO_DOWNLOAD_SKIP_EXISTING pour ne pas écraser les fichiers Compose, et la mise en miroir de l'URL du script d'amorçage. Pour un serveur, la procédure passe par --prepare-only, l'édition de SANDBOX_PROVIDER et RAKAZO_HOST, puis une seconde exécution du script. Point à ne pas manquer : le README écrit qu'il faut placer HTTPS devant le port 5173 et que le client de bureau n'accepte le HTTP que pour loopback et les adresses LAN privées, pas link-local.

Développement depuis les sources : les secrets à générer soi-même

Le checkout local impose des versions précises : Node.js 22.22.2 ou plus récent dans la branche 22.x, Node.js 24.x, ou Node.js 26 et au-delà ; pnpm 9 ; Docker. Les versions 23.x et 25.x ne sont pas prises en charge. Après le clone et la copie de .env.example vers .env, il faut renseigner POSTGRES_PASSWORD, par exemple via openssl rand -hex 16, et reporter la même valeur dans DATABASE_URL. Le README demande aussi de définir BETTER_AUTH_SECRET, ENCRYPTION_KEY et SCREEN_PROXY_SECRET avec des valeurs aléatoires longues et indépendantes, plus un SANDBOX_SUPERVISOR_TOKEN dédié pour les bacs à sable Docker. Les catalogues d'applications managés sont facultatifs : COMPOSIO_API_KEY d'un côté, le trio PIPEDREAM_CLIENT_ID, PIPEDREAM_CLIENT_SECRET et PIPEDREAM_PROJECT_ID de l'autre. La séquence de démarrage enchaîne un docker compose ciblant postgres avec l'overlay postgres-host, puis pnpm install, pnpm db:generate, pnpm db:migrate, pnpm sandbox:build et pnpm dev. L'overlay publie 127.0.0.1:5433 pour les outils côté hôte ; sans lui, il faut ouvrir un shell psql dans le conteneur. Un avertissement mérite d'être cité tel quel dans son intention : un volume pgdata existant conserve utilisateur, mot de passe et base définis à la première initialisation. Si vous changez POSTGRES_PASSWORD dans .env sans toucher à la base, la connexion échoue. Il faut soit garder les valeurs, soit passer par ALTER ROLE ou un renommage, et docker compose down -v détruit tout l'état Postgres.

Le client de bureau installe une pile, il ne s'y connecte pas toujours

Au premier lancement, l'application Electron demande si Rakazo doit tourner sur cet ordinateur ou se connecter à un serveur existant. Le choix local installe et démarre les images publiées avec Docker Compose, sous le répertoire de données de l'application, ce qui suppose Docker Desktop, OrbStack ou Docker Engine installés. Les builds installés épinglent le tag d'image à leur propre version ; les builds non empaquetés tirent edge. Les développeurs qui lancent pnpm dev doivent donc choisir Existing instance avec http://127.0.0.1:5173, sinon ils se retrouvent avec deux piles concurrentes. L'application vérifie le point de terminaison de santé avant d'enregistrer l'instance, et les lancements suivants y vont directement. Un détail de comportement que le README précise et qui surprendra plus d'un utilisateur : la pile continue de tourner après la fermeture de l'application, et l'arrêt se fait par Stop Local Stack dans le menu. Autrement dit, fermer la fenêtre n'arrête ni les conteneurs ni la consommation de ressources.

Ce que le matériel ne permet pas de trancher

Le projet est en beta, et le README le dit sans détour. Trois versions sont sorties en trois jours, v0.1.4 le 7 septembre, v0.1.5 le même jour, v0.1.6 le 8 septembre. Ce rythme indique un développement actif, pas une API figée : prévoyez que les migrations Prisma et les variables d'environnement bougent entre deux mises à jour. Le README ne documente ni procédure de retour arrière, ni compatibilité entre versions de schéma, ni politique de support. Sur les coûts, il faut lire entre les lignes : le fournisseur de modèles est le vôtre via Pi, les bacs à sable distants e2b, daytona et box sont facturés par leurs opérateurs respectifs, et Treg est facturé à l'usage. Le mode vocal exige en plus une clé ElevenLabs, OpenAI, Cartesia ou Fish Audio. Le matériel fourni ne contient aucune mesure de performance, aucune estimation de nombre d'utilisateurs, et aucun chiffre de consommation. Je ne peux donc rien affirmer sur la charge supportée par une instance unique, ni sur le nombre de bots simultanés qu'un serveur absorbe.

Licence Apache-2.0 et conditions tierces

Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial, la modification et la redistribution, avec obligation de conserver les mentions de copyright et le texte de licence, et une clause de brevets. Elle n'impose pas de publier vos modifications. Ce point compte pour un opérateur qui veut intégrer Rakazo dans une offre interne. En revanche, la licence du code ne couvre pas les services appelés : le README signale explicitement que Treg est facturé à l'usage et que les opérateurs qui l'intègrent dans un produit hébergé doivent consulter les conditions d'intégration de Treg, lesquelles exigent un accord écrit pour la revente hébergée. Si vous activez Composio ou Pipedream Connect, ce sont leurs propres conditions qui s'appliquent. Le README précise aussi que les identifiants des connecteurs sont chiffrés sur le serveur et ne sont jamais renvoyés par l'API, ce qui réduit l'exposition mais ne dispense pas de protéger ENCRYPTION_KEY : sa perte rend les identifiants stockés illisibles. Je ne donne pas d'avis juridique ici ; faites relire ces conditions si vous hébergez pour des tiers.

Comparer avec une plateforme d'agents managée

L'alternative la plus directe est une plateforme d'agents managée, du type de celle que le projet vise explicitement en se présentant comme une alternative à Grok Bot. La différence n'est pas cosmétique. Avec un service managé, vous ne générez ni BETTER_AUTH_SECRET ni ENCRYPTION_KEY, vous ne faites pas de migration Prisma, vous ne choisissez pas entre Docker local et E2B, et vous ne placez pas de reverse proxy Caddy devant un port. En échange, vous ne décidez ni du modèle sous-jacent, ni de l'endroit où vivent l'historique et la mémoire des bots, ni de la politique de rétention. Rakazo déplace ces décisions vers vous, y compris celle du fournisseur de bac à sable, ce qui est précisément l'intérêt pour une équipe qui a des contraintes de résidence des données. Le coût de ce contrôle est réel : une base PostgreSQL à sauvegarder, un volume pgdata à ne pas recréer par accident, un .env à protéger, et une mise à jour d'images à suivre. Une seconde alternative, plus légère, consiste à assembler soi-même un orchestrateur d'agents autour d'un serveur MCP et d'un conteneur Docker. Vous perdez la persistance des conversations, les routines, le mode vocal, les ordinateurs partagés et la délégation entre bots, mais vous gardez la main sur chaque brique et vous n'avez pas de schéma Prisma à migrer. Rakazo se justifie quand ces fonctions sont déjà écrites et que vous préférez les exploiter plutôt que les réécrire.

Conclusion éditoriale

Rakazo convient aux équipes techniques qui veulent des bots persistants sur leur propre infrastructure et acceptent de gérer Postgres, Docker et plusieurs secrets. Il ne convient pas à qui cherche un service managé sans exploitation, ni à un déploiement sans HTTPS hors loopback. Avant d'adopter, vérifiez trois points : le contenu de .env généré par install-images.sh, la disponibilité de l'image edge pour votre architecture, et les conditions d'intégration de Treg si vous l'exposez à des utilisateurs.

Sources officielles

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