Busabase gives every agent the same records, and reviews the writes that matter

The problem: every session starts from zero

The argument the project makes is about context loss between agent sessions. Your CLAUDE.md lives in one repository, the best output dies in a chat, and switching tools means explaining the project all over again.

Busabase's answer is to keep the agents stateless and the work durable. Connect any agent, and it reads the same records, docs, skills and apps that your team and other agents already left behind, then writes its own work back with a diff and a history.

That is a different shape from giving an agent a folder of files. A file system is a bag of documents with no type checking and no relations, and an agent that writes to it leaves no trace of what changed or why. A workspace where nodes are typed and where writes are recorded as change requests turns the same activity into something a second agent, or a person, can rely on.

The positioning in the README is the system of record for AI agents, and the repository topics place it against Airtable, Notion and Supabase, with local-first, audit-trail and human-in-the-loop named among them. The homepage is busabase.com and the project describes itself as local-first and self-hostable.

One command, embedded Postgres, no account

The quick start is a single command:

npx busabase server

You then open http://localhost:15419/dashboard/local, and the README is explicit that there is no database, account or configuration to set up. The server starts with embedded PGlite, local file storage and a demo workspace.

That last point is the one that changes how you evaluate the thing. PGlite is Postgres running in the process, so the data model is real Postgres and the SQL is real SQL, but there is no server to install and no connection string to configure. The cost of trying the project is one npx invocation.

Other routes are documented in a collapsed section. There is a Docker image on Docker Hub and on GHCR, a global install through npm with a busabase-cli client, and a from-source path that expects pnpm:

npm i -g busabase       # then: busabase server
npx busabase-cli --help # API client for any Busabase server

pnpm install
cp apps/busabase/.env.example apps/busabase/.env
pnpm --filter busabase dev

A desktop build for macOS, Windows and Linux is linked from busabase.com/download, and it runs locally and works offline.

The Agent Skill is how an agent learns the rules

Connecting an agent is not a plugin install, it is a prompt. The README tells you to paste a block into Claude Code, Codex, Cursor, Gemini CLI, or any agent that can read a URL. The block points the agent at the skill file and tells it to follow the onboarding, to submit changes rather than pick a merge policy, and to reply in English:

http://localhost:15419/SETUP_SKILL.md

The file at that URL is a SKILL.md playbook served by the running server, and it is described as the single source of truth for the agent. The workspace keeps SKILL.md playbooks and custom prompts, and the Playbooks feature collects them into one catalog that every connected agent can look up before it acts.

The second half of that prompt is the design decision worth noticing. The agent is told not to choose a merge policy itself, but to submit the change and let Busabase apply the workspace permissions to decide whether it merges immediately or waits for review. The policy lives in the workspace, where you can change it, rather than in the prompt of whichever agent happens to be running.

The test the README suggests is the honest one: have one agent record a project's updates and conventions, then open a different agent and ask what changed on this project this week. It answers from the workspace rather than from the clipboard.

Writes travel as Change Requests with a field-level diff

Every write is accounted for, and the mechanism is specific. Agent writes travel as Change Requests carrying a message, a field-level diff, an author and a history. Permissions then decide whether a change merges on the spot or waits for review.

Field-level is the operative word. A diff of whole files tells you what changed but not which field, and a reviewer looking at a busy workspace needs to know whether an agent changed a status field or a date. The README also describes a dashboard card showing the workspace home with a review queue, recently visited knowledge and agent activity, which is the human side of that same mechanism.

This is the human-in-the-loop claim made concrete. The agent is not blocked from proposing; it proposes, and the workspace decides. That is a clearly different design from an agent that writes directly and a human that reads the log afterwards, and it is the difference between a review queue and an audit trail.

The repository topics name audit-trail and human-in-the-loop alongside agent-workspace and agentic-ai, and the feature list describes the pieces that live in the tree: Bases holding typed records, relations, views and forms, plus Docs, Files, Drives, Skills, AirApps, Whiteboards and Workflows as first-class nodes in one tree.

Bases, AirApps and templates as a way in

Three features are about how a workspace gets populated rather than how it is queried.

Bases are the typed record layer, with records, relations, views and forms, and they are the closest thing to a table in a conventional application. Views and forms on top of a base is the Airtable shape, which is why the repository topics include airtable-alternative.

AirApps are apps that run inside Busabase on workspace data. The stated use is asking an agent to turn a Base into a dashboard, a CRM or a content desk, and each app comes with a SKILL.md the next agent can read. So an app built by one agent is discoverable and usable by the next one, which is the durable-output part of the pitch.

Templates are the third. They install a whole working setup in one command, and the description is precise about what that includes: Bases, views, docs, sample data, apps and its agent manual. For a team that has been arguing about what shape their shared knowledge should take, that is a starting point rather than a blank workspace.

There is also the bring your own agent part, and the emphasis is on no lock-in. The listed integration paths are the Agent Skill, MCP, OpenAPI, the CLI, or an ACP chat session, and the project states there is no built-in model. The README carries a Glama MCP connector badge, so MCP is one of the supported doors.

Where the data lives, and the one-process limit

Local data lives under the home directory in a .busabase folder, with a pgdata directory for the embedded PGlite database and a storage directory for files. Three environment variables redirect it: BUSABASE_DATA_DIR for another location, PG_DATABASE_URL for an external Postgres, and STORAGE_URL for S3-compatible storage.

That is a genuine escape hatch and it is worth knowing when the embedded setup stops being enough. Moving the database to an external Postgres keeps the same engine and the same schema, and pointing storage at S3-compatible storage separates the files from the machine.

There is one constraint that catches people out, and it is stated plainly: only one process can hold the same PGlite database at a time. So a second server instance against the same data directory will not work, which rules out running two workspace copies against one folder, and it is also why the Docker command mounts a dedicated path at /data rather than reusing the local one.

The Docker route shows the shape of a self-hosted deployment:

docker run --rm -p 15419:15419 -v ~/.busabase/data:/data busabase/busabase

The port 15419 is the same one the local dashboard uses, so the URL you already know keeps working when you move to a container.

A pnpm monorepo shipping an npm package, a CLI and a Docker image

The repository is a pnpm workspace with apps and packages directories and a pnpm-workspace.yaml, and the root package.json is private with the version 0.96.0. The package manager is pinned to pnpm 10.15.1, and the scripts are all filtered calls, dev, build, start, typecheck, lint and test all delegating to the busabase app, with separate database scripts for generate, migrate and seed.

The distribution is broader than the repository. There is an npm package for the app and a separate one for busabase-cli, a Docker image on Docker Hub, a desktop build using Tauri for macOS, Windows and Linux, and the same engine is said to power Busabase Cloud, the hosted offering. The MIT licence covers the codebase, and the same engine serving both the local build and the cloud product is the clearest statement of the architecture in the whole project.

The release cadence is fast. The tags are v0.96.0 from 2026-10-19, v0.95.1 from 2026-10-08 and v0.95.0 from 2026-10-07, and the last push was on 2026-10-22, three days after the newest tag. The version is still below 1.0, so the API surface for anything you script against may still move, and the repository carries a patches directory with patched dependencies, which is the usual sign of a young project working around upstream issues in React Native and node tooling.

Editorial conclusion

Adopt Busabase if you run more than one agent against the same body of work and keep losing context between sessions, since the shared workspace is the whole point and the review queue is what makes an agent write safe to accept. Do not adopt it if your work fits in one repository's CLAUDE.md, since the extra moving parts are only worth it once the state has to outlive a chat window. Before you install, check three things: that you have Node available for the npx route, where the local data directory sits and whether another process already holds the embedded PGlite database, and how your agents will be given the Agent Skill, since the onboarding prompt asks them not to choose a merge policy themselves.

Frequently asked questions

Official sources

1. busabase/busabase on GitHub
2. License: MIT
3. Project website
4. README
5. Releases