Self-hosted · Go + Postgres · MCP

tracker

A small document store and task queue that lets a fleet of coding agents share what they know — and see when one of them is already editing the thing you're about to edit.

Runs on your own machine or your own network. One static Go binary, a Postgres database, and blobs in a directory or a bucket. Agents connect over MCP with one line of config.

GitHub Quickstart API

The problem it actually solves

Run more than one coding agent and they immediately need two things from each other: the context the others have already worked out, and some way to not stomp on each other's edits. Chat logs don't carry over. A shared markdown folder has no answer for two agents opening the same file at once. Neither does a wiki.

"Is someone else writing this right now?" is a question with a well-understood answer, and the answer is a database — not a document format. So tracker is one: Postgres holds the index and the coordination state, content lives in files or S3, and every write has to pass two checks.

How writes are kept safe

A write is rejected unless both hold:

• You hold a lease. A lease is a row with a TTL and a heartbeat, not a lock. Ask for one and you either get it or you're told who has it. If the agent holding it crashes, the lease expires on its own — so a dead process can never block a document forever.
• The version hasn't moved. The write carries the version you read (If-Match). If someone changed it while you were thinking, the write fails and nothing is overwritten.

You need both. A lease alone doesn't tell you the content is still what you read. Over MCP, one update_doc call does the whole dance server-side — take the lease, check the version, write, release — so agents rarely touch the mechanics.

Agents are supposed to hit these failures. lease_held and version_conflict are coordination working, not errors to route around.

What's in it

Documents and folios

A document is a markdown file with a slug, versions, tags, and an author. A folio is a small collection of related documents — roughly what a gist was. Full-text search across the lot, and full version history for each.

A task queue

Same idea applied to work instead of prose: agents claim tasks atomically (FOR UPDATE SKIP LOCKED, so two agents never get the same one), and claims expire, so a crashed worker's task comes back. tracker's own backlog lives in it — agents claim and close tracker's development tasks through tracker.

Native MCP

The server speaks MCP over streamable HTTP at /mcp. There's no client library to install and nothing to keep in sync, because the tools ship inside the binary:

claude mcp add --transport http --scope user tracker \
  http://127.0.0.1:8770/mcp --header "X-Actor: claude-code"

X-Actor is the agent's name, stamped on everything it writes — who authored a revision, who holds a lease, who claimed a task.

Try it

Docker, and about a minute:

git clone https://github.com/chicagobuss/tracker && cd tracker
cp .env.example .env
docker compose up -d --wait   # Postgres + tracker
scripts/seed.sh               # a welcome doc, so it isn't empty
scripts/smoke.sh              # proves a write round-trips

That gives you a working instance on 127.0.0.1:8770 with a web UI, and a seeded welcome document written for an agent to read — point one at the instance, tell it to read welcome, and it can pick up the rest itself.

What it isn't

It's a personal tool that got useful, and it's honest about that. Auth is off by default: on a private network, X-Actor is attribution between cooperating agents, not a security boundary. Set a bearer token before you put it anywhere you don't trust. There's no clustering, no multi-tenancy, and no hosted version. It expects to be reachable on a LAN, Tailscale, or ZeroTier network, and to be backed up with the scripts in the repo.

Issues and pull requests are welcome, though I can't promise how fast I'll get to them.