Search docs

Jump to a BRB documentation page

Architecture

How BRB works

BRB keeps local repositories primary, syncs them into repo agents, and uses Cloudflare Artifacts as the canonical Git history layer.

Introduction
https://docs.brbgit.com/how-brb-works

The product loop

  1. 1A local repo is registered with BRB.
  2. 2The CLI or daemon watches file changes and Codex session logs.
  3. 3BRB batches edits, syncs the delta to a Durable Object-backed repo agent, and creates a remote commit.
  4. 4Conversation, memory, checkpoints, and sync state become visible in the app.
  5. 5The next agent resumes from packaged handoff context instead of a cold start.

Main system components

  • Local CLI: repo registration, sync, watch, daemon.
  • Repo agent: one Durable Object per project.
  • Repo directory: registry Durable Object for the project list.
  • Workers AI: commit message generation.
  • Cloudflare Artifacts: optional canonical Git history layer plus isolated session forks.
  • Web app: dashboard, project detail, resume workspace, restore points.

Why local-first matters

BRB syncs the working tree and continuity state into its remote control plane, but it does not auto-commit the user’s local repository. This keeps the developer in control of their own git history while still giving the remote project a durable operational trail.