Every small project eventually wants a forum, and every forum eventually wants a server. Accounts, sessions, a database, spam moderation, email verification, backups — the infrastructure bill for "a place to talk" is absurdly out of proportion to the feature. Discussion Kit is my answer: a fully featured forum site powered entirely by GitHub Discussions. No backend. No database. Just static files on GitHub Pages and GitHub's GraphQL API doing all the heavy lifting.
If your project lives on GitHub, you already have a forum — it's called Discussions. It has threads, categories, replies, reactions, upvotes, markdown, notifications, moderation, and an account system with billions of users. What it doesn't have is your branding, your URL, or a browsing experience designed for a community rather than a repository.
Discussion Kit is a translation layer. It maps forum concepts one-to-one onto Discussions primitives:
| Forum concept | GitHub Discussions primitive |
|---|---|
| Topics / sections | Discussion categories |
| Posts | Discussions |
| Comments & threaded replies | Discussion comments and replies |
| Reactions & upvotes | Native reactions and upvotes |
| Pinned posts | Discussions pinned on github.com |
| Moderation | GitHub's own moderation tools |
Everything is bidirectional because there's only one source of truth. A post made on the forum is a discussion in the repo; a reply left on github.com shows up threaded on the site. There's no sync job because there's nothing to sync.
The site is built with Svelte 5, SvelteKit, and Tailwind CSS v4, compiled with adapter-static into plain files and deployed to GitHub Pages by a GitHub Actions workflow. At runtime the browser talks directly to GitHub's GraphQL API — the "backend" is GitHub's own infrastructure.
A few details do the interesting work:
/d/42 can't be prerendered, so the build ships a 404.html fallback that boots the SvelteKit router client-side. GitHub Pages serves it for any unknown path, and the app takes over. (Plus the classic .nojekyll file so Pages doesn't eat the _app/ directory.)bodyHTML: GitHub-flavored markdown already rendered, syntax-highlighted, and sanitised by GitHub itself. The client never parses user markdown, which removes an entire class of XSS surface.localStorage (default one hour) so repeat visits paint instantly while fresh data loads behind the scenes.Reads and writes go through the GitHub API, so users need a token. There are two modes:
A forum needs more than threads to feel like a forum, and this is where it got fun to build.
An optional reputation system awards points for participation — 5 for a post, 2 for a comment, 15 for an accepted answer — with daily caps to stop farming. Topics can require minimum rep to post. But here's the constraint: with no backend, there's nothing to block a low-rep post at submission time. So enforcement is reactive: a scheduled job sweeps violations within 48 hours and moves, locks, or deletes them with an explanatory comment. It's moderation as eventual consistency, and for a community forum that trade-off works.
The API requires authentication, which would make the forum invisible to anonymous visitors. The optional archive feature fixes that with event-driven snapshots: whenever discussions change, a workflow captures the GitHub-rendered HTML, comments, and reactions into static files. Signed-out users browse the archive anonymously with degraded features (no posting, reactions, or search); signing in upgrades them to the live forum.
Both features need somewhere to store machine-generated state — rep profiles, cached post content, category metadata. It lives in an orphan data branch: committed by bots, never merged into main, invisible to your CI/CD. The repository is quietly doing double duty as the database after all — just in a corner where it can't hurt anyone.
Everything lives in one forum.config.ts: site name and logo, navigation links, admin usernames (which get badges on their posts), custom badge categories, page size and sorting, feature toggles for search/reactions/upvotes, per-scheme theme tokens for light and dark mode, cache TTL, and the reputation and archive settings. No forking of core code to customise.
The whole point is that setup is boring:
main — the deploy workflow auto-detects the repository and publishesforum.config.ts and deploy the OAuth proxy for one-click sign-inSomeone on the Product Hunt launch had a working forum in ten minutes, posts appearing in both the site and the repo's Discussions tab. That's the whole pitch in one sentence.
The logic modules — config parsing, the GitHub API layer, auth, permissions — sit under Vitest with 100% coverage, enforced in CI. Every pull request and every Pages deployment is gated on it. On a project whose entire job is translating between two systems' data models, the test suite is what makes refactoring the mapping safe.
Discussion Kit isn't trying to replace Discourse for a hundred-thousand-member community. It's for open-source projects, documentation sites, product feedback portals — teams already living on GitHub who want a real community space without another platform to manage, another database to back up, or another auth system to secure. Small projects don't need forum infrastructure; they need a forum. GitHub already built the infrastructure.
The project is GPL-3.0 and open source at NotReeceHarris/discussion-kit. It launched on Product Hunt, and there's a companion write-up on dev.to walking through the build.