So we changed three letters. Our entire version-control client fleet now gits far — every client speaks to api.gitfar.com instead of api.github.com, the same GitHub REST wire protocol answered from the git repositories on our own disks. The arbitrary ceilings — requests per hour, search results, storage tiers — simply aren't there. The only limit left is the hardware.
−https://api.github.com
+https://api.gitfar.com
three letters in the origin — and the whole fleet gits far
01The ceilings you leave behind
Run it local. Leave the limits at the door.
API requestsGitHub throttles every authenticated call
5,000 / hr→no limiter
Code search resultsGitHub's hard search-window ceiling
1,000 max→unbounded
Repository storagesize policed by your account tier
tiered caps→your disk
GitFar keeps a few sane engineering guards — a 1 MB blob scan and a 5,000-file pass per search — but none of them are account tiers, quotas, or clocks.
02Why you can trust it
Three decisions that make it safe to run anywhere.
i
git is authoritative
The on-disk repository is the only store. There is no repository catalog, no metadata cache, no token table — nothing that can fall out of sync, because there is nothing to sync. git repository state is authoritative.
ii
Zero dependencies
No npm, no JSR, no CDN imports, no vendored packages. The whole service is the Bun runtime and the git CLI — small enough to read end to end, inspectable by design.
iii
Wire-compatible, not just inspired
Identical endpoints, JSON shapes, and strong ETags. Playground-only behavior rides on explicit x-gitfar-* headers so GitHub semantics are never quietly changed underneath you.
“git repository state is authoritative; GitFar has no repository database.”