DistroDB

DistroDB (distrodb.xyz) is a self-directed NSWEB product: an open-source database of Linux distributions built to replace the decades-old, visually flat experience of sites like Distrowatch with something that actually looks like 2026 — card-based discovery, native dark mode, and screenshots that sell the desktop instead of a table of rankings nobody trusts.

NSWEB owns the platform end to end — the Next.js storefront, the Payload CMS backend that structures over a hundred distributions' worth of technical data, and the interactive tools (a comparison engine, a recommendation wizard) that turn a static database into something people actually want to use.

1. DistroDB's homepage — live distro count, quick-filter chips, and card-based discovery

The Challenge

Distrowatch has been the default reference for Linux distributions for over two decades, and it shows — a page-hit ranking that rewards being old and well-known rather than good, information buried in dense text tables, and zero help for the actual question a visitor has: "which one of these hundred distros is for me?"

Rebuilding that as an open-source project surfaced its own set of constraints:

• A "distro" isn't one shape of data. Base distribution, package manager, init system, release model, supported architectures, desktop environments — every one of these varies independently, and a schema that's too rigid breaks the moment an atomic or immutable distro (which doesn't cleanly fit "mutable" fields) needs a page.
• Recommendation is a scoring problem, not a filter problem. "Find me a distro" isn't a set of AND conditions — it's a weighted match across experience level, use case, and preferences that has to run instantly, client-side, without a round trip per answer.
• Content has to stay open to contribution without becoming a free-for-all. Anyone can spot a wrong package manager or a missing distro, but letting arbitrary edits land straight into the database isn't an option for a public reference site.
• "Popular" needed an honest definition. Distrowatch-style page-hit rankings measure curiosity, not usage — a credible popularity signal had to come from somewhere real.

Our Solutions

Next.js

React

Typescript

Payload CMS

PostgreSQL

Tailwind CSS

Docker

GitHub

1. A CMS-backed schema built for genuinely different distros

Distro data lives in Payload CMS on Postgres, not in flat files — the distros collection mirrors a shared DistroDetail type so the same schema drives the web app, the detail pages, and the comparison views. Base, package manager, init system, release model, architectures, and desktop environments are all structured fields rather than free text, which is what makes exact filtering and side-by-side comparison possible in the first place instead of approximate string matching.

Logos and screenshots are Payload uploads backed by S3-compatible storage, editable per-distro from the admin UI — adding or correcting a distro is a CMS edit, not a file drop and a redeploy.

2. Structured technical specs per distro — base, package manager, init system, release model, and architecture support, all filterable fields, not prose

2. A wizard that scores, not filters

The Distro Wizard asks six questions — Linux experience, primary use case, hardware, and a few preference signals — and scores every distro in the database against the answers entirely client-side. The distro list is fetched once, server-side, and handed down as a prop; from there, scoring and re-ranking happen instantly in the browser with no network round trip per question, so the quiz feels immediate instead of like a form submission.

3. The Distro Wizard — six questions, scored client-side, no page reload between steps

3. Comparison and popularity as first-class pages, not afterthoughts

Any two distros can be compared head-to-head at a stable, statically generated /vs/{slug-a}-vs-{slug-b} URL, with matching fields highlighted so the difference is visible at a glance instead of buried in two open tabs. A separate /popularity page replaces Distrowatch's page-hit ranking with something measured: a "gamers" rating scraped and parsed server-side from the Steam Hardware Survey's Linux breakdown, aggregated across versions of the same distro and cached daily — a real usage signal for one specific audience, clearly labeled as such rather than dressed up as overall market share.

4. Side-by-side comparison pages — matching specs highlighted, generated statically per distro pair

4. Open contribution without an open write path

The database itself isn't editable through a normal pull request — data corrections and new-distro submissions go through structured GitHub issue forms (or the in-app "Suggest a change" button), reviewed before anything reaches Postgres. Code contributions follow the standard fork-and-PR flow, but the data layer people actually care about getting wrong stays curated.

5. A deploy path that survives its own build-time dependency

The web app statically generates distro, comparison, and glossary pages straight from the CMS's REST API at build time, which means the CMS has to be up and reachable before the web image can build — a two-phase deploy, not a single docker compose up. On platforms like Coolify that build every service in a compose file simultaneously, that ordering requirement can't be expressed in one stack, so CMS and web ship as two separate deploy resources instead, with the web build pointed at the CMS's own domain. On-demand revalidation closes the loop: a Payload afterChange hook calls back into a /api/revalidate route the moment an editor saves, so CMS edits show up immediately instead of waiting out the hourly cache window.

Outcome

• A live, actively maintained Linux distro database at distrodb.xyz, covering over a hundred distributions with structured, comparable technical specs.
• A recommendation tool that actually recommends, instead of a filter panel dressed up as one — six questions to a scored shortlist, no dead ends.
• An honest popularity signal, sourced from real usage data instead of page hits, with room to add more audience-specific ratings over time.
• A genuinely open project — source on GitHub, a structured path for community-submitted distros and corrections, and a deploy architecture designed to be self-hostable rather than tied to one platform.