Skip to main content
Beads uses Dolt’s native version control for syncing issues across machines and backing up your data. This guide covers sync workflows, backup strategies, and protected branch setups.

Dolt sync overview

Beads uses Dolt (git for data) as its database backend. Every write operation creates a Dolt commit:
Dolt commits form a version history independent of git commits.

Basic sync workflow

1

Configure Dolt remote

Add a remote for syncing (DoltHub, DoltLab, or file-based):
2

Push changes

Push local commits to remote:
Install git hooks to auto-push: bd hooks install --auto-push
3

Pull changes

Pull remote commits:
Dolt handles merges automatically with cell-level 3-way merge.

Sync modes

Direct mode (default)

Issues commit directly to the Dolt database:
Pros:
  • Simple, no extra configuration
  • Immediate Dolt commits
Cons:
  • Dolt commits are separate from git commits
  • Requires explicit push/pull

Protected branch mode

For projects with branch protection (GitHub, GitLab):
Pros:
  • Works with protected branches
  • Beads commits don’t directly touch main
  • Can review metadata changes in PRs
Cons:
  • Requires periodic merges
  • Slightly more complex workflow
See Protected Branch Workflow for detailed setup.

Team sync workflows

Continuous sync (small teams)

Every write auto-pushes:
Best for: 2-5 people, high trust, fast feedback

Periodic sync (larger teams)

Pull before checking ready work, push after completing work:
Best for: 5+ people, async work, less frequent coordination

Branch-based sync (formal processes)

Each agent/developer works on a branch:
Best for: Large teams, code review processes, staged rollouts

Backup strategies

Automated Dolt backups

Use bd backup for automated backups:
1

Initialize backup

This creates a backup repository with full Dolt history.
2

Configure auto-backup

3

Manual backup

Syncs latest changes to backup repo.

JSONL exports

For portable backups:
JSONL exports lose Dolt history. Use Dolt backups for full version control.

Remote redundancy

Push to multiple remotes:

Scheduled backups

Set up cron job:

Conflict resolution

Dolt uses cell-level 3-way merge:

Auto-merge scenarios

Different issues modified:
Different fields modified:

Manual conflict resolution

Same field modified:
Hash-based IDs prevent ID collisions. Conflicts are rare in practice.

Multi-machine setup

Setup on Machine 1

Setup on Machine 2

Ongoing workflow

Machine 1:
Machine 2:

Recovery scenarios

Lost local database

Restore from backup

Time travel

Restore to previous state:
Use dolt reset --hard carefully. It discards all changes after the specified commit.

Performance considerations

Large databases

For repositories with 10,000+ issues:

Network optimization

Troubleshooting

Push fails: “ref update failed”

Cause: Remote has commits you don’t have. Solution:

Pull fails: “merge conflict”

Cause: Conflicting changes on same field. Solution:

Remote not found

Cause: Remote not configured or incorrect URL. Solution:

See also