OpenViSTAI · Agents · Blockchain · Crypto
Submit a project
Menu
Agent Memory & RAG

Busabase

Busabase is an open-source context database and workspace where people and AI agents share structured records, documents, skills and apps, with authored change history.

Explore the practical guide ↓

Independent OpenViST project profile, based on linked sources.

Busabase — OpenViST project profile in Agent Memory & RAG.
OpenViST project illustration. See the linked sources for product details.
Understand the project

Practical overview

When it fits

Use Busabase when agents and people need to build on shared records, documentation or skills, especially when changes need attributable history or selected writes should wait for human review.

Who it is for

  • Teams that want agent work and reusable context to persist in a shared workspace.
  • People connecting agents that can use MCP or HTTP-based interfaces.
  • Operators choosing between a local run, self-hosting and Busabase Cloud.

Documented uses

  • Keep reusable records of agent work across sessions.
  • Share and update structured data and documentation with agents and teammates.
  • Save skills and playbooks for agents to reuse.
  • Review selected proposed changes and inspect or undo recorded edits.
Before you choose

Requirements & limits

The documentation describes local, self-hosted and Busabase Cloud options. It identifies Busabase as open-source under the MIT licence.

  • Busabase does not include a model; users bring an agent.
  • Agent access is described through MCP, an agent skill, the CLI or REST API.
  • Human review is optional and configured per credential or individual write; agents with write access can otherwise merge immediately.
  • Self-hosting guidance distinguishes a Compose deployment, whose app container runs as non-root, from an all-in-one image that runs as root inside the container.

Check current requirements in the official documentation. Source-based guidance does not mean OpenViST has run or independently tested this project.

Source-based practical guide

Harden a Busabase self-hosted deployment

Apply the documented network, TLS, secret-handling, and administrator-email safeguards to a self-hosted instance.

Before you start

  • A self-hosted Busabase deployment using Docker Compose or the all-in-one image.
  • A reverse proxy capable of providing TLS.

Steps

  1. Put the app on port 3000 and the published SeaweedFS port 8333 behind the same TLS-enabled reverse proxy; set APP_URL to the HTTPS address.

  2. Restrict firewall access to port 3000 so only the proxy can reach it. Do not publish Postgres port 5432 or SeaweedFS port 9333.

  3. Protect .env and /data/.credentials as production secrets, and back them up somewhere with equivalent protection.

  4. Set SYSTEM_ADMIN_EMAIL to a real, monitored address. Rotate BETTER_AUTH_SECRET if it may have been exposed, noting that rotation invalidates existing sessions.

Expected outcome

The deployment follows the documented TLS, network exposure, secret protection, and administrator-contact hardening measures.

Guide limitations

  • The all-in-one image runs as root inside its container; use the Compose deployment if policy forbids root inside containers.
  • Busabase does not cover host-level access in its audit controls; host shell and Docker access remain trust boundaries.
  • External S3, SMTP, or agent-provider connections can send data outside your network if configured.
Documentation 1 ↗
Evidence and transparency

Sources & review

busabase.com ↗Guide documentation ↗
Source record details
Source availability
Active
Sources checked
7 November 2026
Original website title
Busabase: The Base for Agents · Official homepage title · retained in its source language
How we review sourcesSuggest a correction