What is octopool?

Octopool is a self-hosted relay and cache for GitHub API read requests, designed for teams that keep hitting GitHub's rate limits. GitHub limits how many API requests each account can make per hour. When a team has multiple developers plus bots all making the same read-only calls (checking pull request status, listing issues, viewing CI run results), they each burn through their individual allowance separately, even though they are often asking for exactly the same data. Octopool addresses this by sitting in between your team and GitHub and caching the results. The way it works is that you deploy a small server (a Cloudflare Worker) that holds all your team's GitHub credentials (personal access tokens or GitHub App keys). When someone on your team makes a read request, the Worker checks its cache first. If the data is already there, it returns it without touching GitHub at all. If not, it picks the credential with the most remaining rate limit budget, fetches from GitHub, and stores the result so the next person gets it from the cache instead. Your actual credentials never leave the Worker, team members authenticate with short-lived tokens that the Worker issues. Access is restricted to members of one GitHub organization, and only public repositories are served through the pool. Private repository requests fall through to the user's own GitHub credentials. The README is clear that this is only useful for teams that actually run into rate limit problems, if that is not a concern, you do not need it. Deployment requires a Cloudflare account on a paid plan (because it uses Durable Objects and D1, which are Cloudflare's stateful and database features), a GitHub org for membership verification, and at least one GitHub credential to pool. A command-line tool called octopool can be used as a drop-in replacement for the standard gh CLI, routing safe read commands through the pool and falling back to your real gh for writes and mutations.