RepoRadar
Open-source intelligence on trending GitHub repositories, updated twice a day.
The git repository itself is the database; content pages are still fully
static, with a couple of small serverless routes for GitHub login.
- Daily, weekly, and monthly trending reports with a featured repository each period
- Per-repo profiles: star history charts, star-jump detection, what it does, use
cases, tech stack, contributors, license, first commit, commit counts
- List views with multi-select topic filtering on trending/topic/language pages
- Browse by topic and language; in-browser search (Pagefind); localStorage watchlist
- Request a repository: sign in with GitHub, describe what you're looking for, and
the site opens a GitHub Issue (as you) that a workflow resolves automatically —
it searches GitHub by stars/relevance, adds the best match to tracking, comments
the result, and closes the issue
- SEO/AEO: JSON-LD structured data, sitemap, RSS feed,
llms.txt
- Cloudflare Web Analytics (cookieless, includes Core Web Vitals) for real traffic and performance data
- Near-zero infrastructure cost: static Next.js export on Cloudflare Pages, data via GitHub Actions
Architecture
GitHub Actions (cron 06:15 + 18:15 UTC, plus hourly-refresh.yml every hour)
scripts/fetch-trending.mjs -> data/trending/<date>.json (scrapes github.com/trending)
scripts/update-repos.mjs -> data/repos/<owner>__<name>.json (GitHub REST/GraphQL + daily star snapshot)
scripts/enrich.mjs -> aiSummary via GitHub Models API (free, falls back to template)
scripts/generate-reports.mjs -> content/reports/{daily,weekly,monthly}/<slug>.md
scripts/process-repo-requests.mjs -> resolves open `repo-request` issues, adds matches to data/repos/
git commit + push -> deploy-cloudflare.yml builds on a runner and uploads out/ (every 2h + on code changes)
Runtime (Cloudflare Pages Functions, functions/)
/api/auth/* -> GitHub OAuth login (encrypted HttpOnly session cookie; no accounts, no user table)
/api/request-repo -> creates a GitHub Issue as the signed-in user
/api/mcp -> MCP server over the static JSON in out/mcp-data
everything else -> static HTML from `next build` (output: "export")
The site is a static export, built in GitHub Actions rather than on the host.
The only server-side code is the Functions above, existing because GitHub's
OAuth token exchange needs a secret that can never live in browser JavaScript.
The build prunes client-navigation payloads for repo pages (scripts/prune-export.mjs)
to stay under Cloudflare Pages' 20,000-file limit. Star history accumulates one snapshot per day per
tracked repo, so charts and "biggest gainers" get richer every day the
pipeline runs.
Why the search index build changed
Pagefind needs a folder of rendered HTML to crawl. The site used to produce
that for free via output: "export", but static export disables API routes
entirely, so login required dropping it. scripts/build-search-index.mjs
replaces that: it starts the built app with next start, fetches every known
content URL (enumerated straight from data/ and content/, no guessing),
saves the HTML into .crawl/, and runs Pagefind against that folder into
public/pagefind/ — which Next serves as static files at /pagefind/*,
exactly where the existing search component already looked. No frontend
changes were needed; npm run build still does everything in one command.
Local development
npm ci
npm run dev # dev server (search index unavailable in dev)
npm run build # build + crawl-based search index (see above)
GITHUB_TOKEN=$(gh auth token) npm run pipeline:morning # run the data pipeline locally
For login to work locally, create .env.local with AUTH_SECRET (any random
string — openssl rand -base64 32) and a GitHub OAuth App's AUTH_GITHUB_ID /
AUTH_GITHUB_SECRET (see the deployment checklist below for creating one).
Running costs and autopilot reality
Measured, not estimated (numbers from real runs on this repository, including
actual GitHub Actions executions, not just local tests):
| Resource | Free allowance | What this project uses |
|---|
| GitHub Actions minutes | Unlimited (public repo) | ~45s per run; 26 runs/day (24 hourly + morning + evening) ≈ 20 min/day, all free regardless |
| GitHub REST API | 5,000/hour observed with GITHUB_TOKEN in Actions on this repo (GitHub documents 1,000/hour per repository for Actions tokens — treat 1,000 as the planning floor) | ~40 calls/run at today's scale (40 tracked repos); auto-scales with population, see below |
| GitHub Models (AI summaries) | ~50 requests/day for openai/gpt-4o on the free tier | 1 call per newly-tracked or stale-summary repo, capped at 20 per run |
| GH Archive on ClickHouse (star history) | Public, anonymous | 1 batched query per run, only for repos missing history |
| Cloudflare Pages | Unlimited bandwidth; direct-upload deploys are not build-minute metered | 12 deploys/day (every 2h), built on GitHub Actions in ~1 min |
| Buttondown | 100 subscribers | RSS-to-email, no code |
Safety behaviour built in: the pipeline reports its own API usage every run,
stops starting new work below a rate-limit floor (deferring repos to the next
run rather than failing), staggers deep refreshes across days so they never
all come due at once, and stops enrichment cleanly when the model quota is hit.
Do you need Jules?
No. The site is fully autonomous on GitHub Actions alone: the workflows collect
data, generate reports, commit, and the deploy workflow publishes them. Jules is an optional
editorial layer that rewrites the human-voice paragraph between the
<!-- jules:editorial --> markers and improves any summary still marked
"source": "template". Without Jules, those sections keep their generated text.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
