ClaraVerse: A Self-Hosted AI Workspace That Puts Agents and Memory First

What ClaraVerse Actually Replaces

ClaraVerse positions itself as a private AI workspace that replaces ChatGPT, Claude, N8N, and image generation tools with a single self-hosted application. The target user is someone who already runs local models through Ollama or LM Studio and wants a chat interface plus automation and agentic features without relying on external APIs. The README emphasizes three pillars: agents that work as a team with human review, a memory system that behaves like a real memory rather than a flat note list, and a license that does not start charging once your project gains traction. That last point is ironic because the repository metadata shows NOASSERTION, not AGPL-3.0, despite the README badge. This discrepancy is a red flag for anyone evaluating the project for legal compliance.

The Architecture: Chat, Crew, Workflow, and Memory in One Container

The application is a TypeScript project that runs as a web service on port 3000. The full stack, as described in the Docker Compose file, includes MySQL, MongoDB, Redis, SearXNG, Qdrant, and an embeddings sidecar. The single-container mode, which you can run with a simple docker run command, boots fine but does not include the sidecars needed for the Knowledge tab or the search_knowledge tool. The README warns that without these components you will see an 'embeddings service unreachable' error. This means the default quick start, which suggests a one-line install or a single docker run, is not sufficient for RAG functionality. The full Compose setup is the only way to get knowledge bases working, and that requires more resources and configuration.

Installation Paths and What Each One Gives You

There are three documented installation routes. The one-line install for Linux and macOS is curl -fsSL https://raw.githubusercontent.com/claraverse-space/ClaraVerse/main/cli/install.sh | bash && claraverse init. That script presumably installs the CLI and initializes the project, but the README does not detail what init does. The Docker Compose route is more explicit: clone the repo, run docker compose -f docker-compose.production.yml up -d, then open http://localhost:3000 and register the first user as admin. The single-container route uses docker run with volume mounts for data and uploads, plus a host-gateway alias. Each route has different capabilities. The one-line install is for the web app plus the terminal agent, while the single-container mode is explicitly partial. This split is a source of confusion for new users who expect a one-command deploy to include all advertised features.

Local Model Auto-Detection and Its Hidden Gotcha

ClaraVerse automatically detects Ollama and LM Studio running on the host machine. The discovery process runs every two minutes. When a provider is found, models are imported, a provider is created, and visibility is set. When the provider goes offline, it is disabled, and when it returns, models are re-imported. The default URLs are http://host.docker.internal:11434 for Ollama and http://host.docker.internal:1234 for LM Studio. The critical gotcha is that Ollama defaults to 127.0.0.1, which is unreachable from inside a Docker container. You must set OLLAMA_HOST=0.0.0.0 in the Ollama configuration, either via systemd or another method. The README provides the exact systemd edit. This is a concrete, non-obvious step that will trip up many users who expect zero configuration after the auto-detection promise.

Crew and Memory: The Two Features That Stand Out

The Crew feature lets you give a project a brief, 'hire' a team of agents, and work through a card pipeline. Each card comes back for human review before it ships. This is a meaningful design choice: it avoids the black-box agent behavior common in other tools. The memory system is layered. There is a pinned tier for facts that should always be injected, such as allergies or hard constraints, and a recall tier for everything else, retrieved by embedding similarity. Memories decay over time if unused and archive themselves. The model calls search_memory and add_memory as tools during a conversation, which means memory is not a separate side channel but part of the model's tool use. Memories are encrypted at rest with AES-256-GCM, with a key derived per user via HKDF, so even an admin cannot read them. These two features are the most concrete reasons to consider ClaraVerse over a plain chat UI.

The Terminal Agent and the CLI

ClaraVerse includes Clara Agent, a coding agent that runs in your terminal and is shipped in the same repository. You install it with claraverse agent install, which builds the agent and puts claracli on your PATH. Then you run claracli and use /login claraverse to connect it to the same account and model as the web app. The agent reads, writes, edits files, and runs commands on your machine. This is a significant addition because it means the same assistant you use in the browser can operate on your filesystem. However, the README does not specify what safety mechanisms exist beyond the human review in Crew. Running a coding agent that can execute commands is inherently risky, and the material does not describe any sandboxing or confirmation prompts for the terminal agent. That gap is worth investigating before you give it access to sensitive directories.

Limitations and Wrong-Tool Scenarios

The most obvious limitation is that the single-container mode is not RAG-ready. If you follow the quick start and skip the full Compose stack, you will not get knowledge base features. The README is honest about this, but it is buried in a collapsible details block. Another limitation is that the mobile apps for iOS and Android are mentioned in the description but not documented in the README at all. There are no installation instructions, feature lists, or screenshots for the mobile clients. This makes it impossible to assess their maturity. ClaraVerse is also the wrong tool if you want a fully managed, zero-ops service, because you have to maintain MySQL, MongoDB, Redis, Qdrant, and an embeddings sidecar yourself. Finally, the license ambiguity is a genuine blocker for commercial use. The repository metadata says NOASSERTION, which means the license file is either missing or not recognized by GitHub's detector. The README badge claims AGPL-3.0, but you cannot rely on a badge.

Alternatives and How They Differ

The README explicitly compares ClaraVerse to Open WebUI, which is the most direct alternative. Open WebUI is a self-hosted chat interface that also works with Ollama and OpenAI-compatible APIs, but it does not include a multi-agent crew system, a visual workflow builder, or a layered memory system as core features. Open WebUI focuses on a polished chat experience with model management and basic RAG, but it does not attempt to replace N8N or offer a terminal agent. The difference in approach is that ClaraVerse tries to be an all-in-one workspace, while Open WebUI stays closer to a chat frontend. If you only need a chat UI, Open WebUI is simpler and more mature. If you want agent teams and persistent memory, ClaraVerse's approach is more ambitious, but you accept the complexity of a multi-service backend.

Maintenance, Upgrade Cost, and License Implications

The project is actively developed, with three releases on the same day in May 2026, suggesting a rapid release cadence. The version numbers, v0.2.0 to v0.3.1, indicate pre-1.0 software, so breaking changes are likely. The Docker Compose stack has multiple services, which means upgrading involves coordinating image versions across containers. The README does not describe a migration path or an upgrade procedure beyond the basic restart and down -v commands. The down -v command removes all data, so it is not a safe upgrade path. The license is the biggest concern. The README shows an AGPL-3.0 badge, but the repository metadata says NOASSERTION. If the code is truly AGPL-3.0, that has implications for anyone who modifies and hosts the software: they may be required to release their modifications under the same license. But without a clear LICENSE file, you cannot assume anything. Before adopting ClaraVerse, you must check the repository for a LICENSE file and verify its contents with a lawyer if you plan to redistribute or offer it as a service.

Editorial conclusion

Adopt ClaraVerse if you are a developer or small team that already runs Ollama or LM Studio locally and wants a single web UI that combines chat, agent teams, workflow automation, and memory without sending data to a third party. Do not adopt it if you need a polished, production-grade mobile experience or if you require a clear license for commercial redistribution, since the repository metadata says NOASSERTION even though the README shows an AGPL-3.0 badge. Before committing, verify the actual license file, test the Docker Compose stack with Qdrant and the embeddings sidecar, and confirm that the mobile apps are mature enough for your use case.

Official sources

1. claraverse-space/ClaraVerse on GitHub
2. Issues
3. Project website
4. README
5. Releases