Tracker is a lightweight document and work-tracking system designed around three goals:
1. *Totally self-hosted and 100% private*: I run it over ZeroTier to connect my systems, but Tailscale or just your personal LAN works great as well.
2. *Flexible, immediately usable, & extensible*: It can use S3/R2/etc for the actual document storage if you want object storage, or you can just use local files. I've been running RustFS myself on a small local k8s cluster which emulates S3. It comes with migration tools to switch from one storage system to another, and it is ready to run in many different forms all designed for AI agents to be pointed at it and immediately self-bootstrapped. "Look at the tracker tool at `<ip:port>` and configure your own mcp and skill using the instructions within" is all you need to tell an agent.
3. *Very lightweight, reasonably fast, and designed more for agents to use it well rather than humans*: That being said, it does have a minimal web UI included so you can also browse your documents.
Furthermore, it has a few design quirks which I really wanted—some people will probably love them and others might hate them. You have to remember that I have a... problem? with simply loving computers, so I tend to work from several different machines simultaneously, and that's a major motivating factor here.
- *Flat structure with tags & folios*: Tracker is only slightly opinionated on document storage hierarchy. You can store a massive collection of raw docs in a flat format, or you can use *folios*—which are just documents of `kind='folio'` whose metadata tracks its files (themselves documents tagged with `folio:<slug>`). There is no other way to introduce additional hierarchy; to me, this is a major benefit—I just wanted one big flat space.
- *Explicit locking on everything*: All changes go through an explicit locking mechanism, even simple metadata edits. This is to prevent an agent from reading a stale document before taking action.
- *Strict attribution*: All edits require an actor ID (sent via `X-Actor: <role>@<hostname>/<ip>`). Because I work across Linux, macOS, and Windows simultaneously, it's critical to know exactly which coding agent is doing what, from where, and on which machine.
Tracker is a lightweight document and work-tracking system designed around three goals:
1. *Totally self-hosted and 100% private*: I run it over ZeroTier to connect my systems, but Tailscale or just your personal LAN works great as well.
2. *Flexible, immediately usable, & extensible*: It can use S3/R2/etc for the actual document storage if you want object storage, or you can just use local files. I've been running RustFS myself on a small local k8s cluster which emulates S3. It comes with migration tools to switch from one storage system to another, and it is ready to run in many different forms all designed for AI agents to be pointed at it and immediately self-bootstrapped. "Look at the tracker tool at `<ip:port>` and configure your own mcp and skill using the instructions within" is all you need to tell an agent.
3. *Very lightweight, reasonably fast, and designed more for agents to use it well rather than humans*: That being said, it does have a minimal web UI included so you can also browse your documents.
Furthermore, it has a few design quirks which I really wanted—some people will probably love them and others might hate them. You have to remember that I have a... problem? with simply loving computers, so I tend to work from several different machines simultaneously, and that's a major motivating factor here.
- *Flat structure with tags & folios*: Tracker is only slightly opinionated on document storage hierarchy. You can store a massive collection of raw docs in a flat format, or you can use *folios*—which are just documents of `kind='folio'` whose metadata tracks its files (themselves documents tagged with `folio:<slug>`). There is no other way to introduce additional hierarchy; to me, this is a major benefit—I just wanted one big flat space.
- *Explicit locking on everything*: All changes go through an explicit locking mechanism, even simple metadata edits. This is to prevent an agent from reading a stale document before taking action.
- *Strict attribution*: All edits require an actor ID (sent via `X-Actor: <role>@<hostname>/<ip>`). Because I work across Linux, macOS, and Windows simultaneously, it's critical to know exactly which coding agent is doing what, from where, and on which machine.
More details on my personal blog: https://chicagobuss.dev/projects/personal/tracker/