Sourcey: OpenAPI, Doxygen and rustdoc Rendered to Static HTML at Build Time
Precision documentation from OpenAPI, MCP, Doxygen, and Markdown guides. Static HTML you own.
At a glance
- What is it?
- Sourcey is a TypeScript documentation generator that turns OpenAPI, MCP, Doxygen XML, godoc, rustdoc and Markdown into one static site, with llms.txt emitted from the same build. The judgement: strong fit if you want the output committed and owned, weaker fit if you need hosted previews, per-request rendering, or a licence you can embed freely in a closed product.
- Who is it for?
- Adopt Sourcey if your docs must be committed artifacts you host yourself and your sources are OpenAPI, Doxygen XML, godoc, rustdoc or Markdown. Do not adopt it if you need runtime rendering, a hosted editing dashboard, or an AGPL-3.0-free dependency in a closed product.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Sourcey fills: one build, several documentation sources
Most documentation pipelines are assembled rather than designed. An OpenAPI renderer here, a Doxygen-to-Sphinx chain there, a hand-written Markdown sidebar that drifts every quarter. Sourcey's pitch is that these become inputs to a single build. The README lists OpenAPI 2.0 through 3.2, MCP server definitions, Doxygen XML, godoc, nightly rustdoc JSON, MkDocs sources and plain Markdown as accepted inputs, with reference pages, guides, changelog, roadmap, search and llms.txt all produced from the same run. The audience is API teams who already have machine-readable specs and want the output to be a directory of HTML they control. The README states the model plainly: everything renders at build time, with no dashboard, no runtime and no API calls to render your own documentation. That single sentence determines both what the tool is good at and where it will frustrate you.
Build-time rendering and what it removes from the deployment
The mechanism is a static site generator with adapters. Each input format has a converter that normalises it into a documentation graph, and the output is HTML plus llms.txt and llms-full.txt as alternate views of that same graph. Nothing is resolved in the browser beyond search and navigation. The practical consequence is that the deployable artifact is a folder, which the README says can go to GitHub Pages, Vercel, Netlify, S3 or anywhere else. There is no server component to keep warm and no vendor holding your rendered pages. The cost is equally concrete: a spec change requires a rebuild and a redeploy. If your team expects a preview URL on every pull request, that has to come from your CI, not from Sourcey. The README points at a sourcey/build-docs GitHub Action for this, which runs the build and deploys to GitHub Pages. That is a CI concern you inherit, not one the tool hides.
Where the adapters actually save work
The Doxygen story is the clearest example of Sourcey taking a position. The README describes feeding Doxygen XML output and getting searchable API docs with exact member search, source links, templates, qualifiers, examples, inherited members and relationship sections, and it explicitly frames this as avoiding a four-tool Breathe, Exhale and Sphinx pipeline. That is a real reduction in moving parts if you maintain C++ code. The Go path is similar: the README says package documentation is extracted from Go source via the toolchain, with no Doxygen detour, and that a separate native binary, sourcey-godoc, exists for Go-only consumers without a JavaScript toolchain. It can emit a static Go docs site or a portable godoc.json snapshot. The Rust path consumes nightly rustdoc JSON through a companion crate and a sourcey-rustdoc converter, and the README notes that snapshot mode lets CI build on a stable Rust toolchain. Each of these is a deliberate replacement of an existing multi-step pipeline, not an additional layer on top of one.
Getting a project running: init, dev, build
The README gives a short path. Scaffold with npx sourcey init, which the README says detects OpenAPI specs and Doxyfiles. Then run sourcey dev for a Vite dev server with SSR hot reload, where spec and markdown changes trigger an instant refresh. Build with sourcey build, which writes static HTML to dist/. There is also a single-spec shortcut: sourcey build api.yaml -o dist/. Configuration lives in sourcey.config.ts using a defineConfig() helper for autocomplete, covering theme, navbar, CTA buttons and footer. Install options are npm (Node 20 or newer), Homebrew via brew tap sourcey/tap, Docker with docker run -v "$PWD":/docs sourcey/sourcey, and Nix flakes. The README mentions a --host flag for containerised dev and refers to docs/install.md for the full Docker invocations for init, dev and build. For Go-only users, sourcey-godoc installs through go install, Homebrew or Scoop. The Rust converter is reached through the sourcey crate on crates.io. One detail worth noting: the README states that an Astro integration can mount Sourcey directly and reads the same sourcey.config.ts, deriving the public siteUrl and baseUrl from it. The supplied material is truncated at that point, so the exact integration API is not something I can describe.
The AGPL-3.0 boundary is the decision most teams get wrong
Sourcey is AGPL-3.0. The README frames this positively, saying you can self-host, fork and extend. That is accurate for the source, but AGPL is a copyleft licence with a network clause, and the README does not attempt to explain the obligations. If you are generating documentation for an open source project, the licence is unlikely to be a practical obstacle. If you intend to embed Sourcey inside a commercial product, or modify it and expose it over a network, the analysis is different and depends on facts about your deployment that this review cannot supply. I am not giving legal advice here, and neither does the repository. Treat the licence as a due diligence item to raise with whoever handles licensing at your organisation before you build a pipeline around it. The presence of a separate Go binary and a separate Rust crate does not change the licence of the project as a whole.
Limitations: multi-document refs, snapshots and version drift
The build-time model has failure modes worth naming. The README advertises $self-aware refs for multi-document APIs, which implies that multi-file specs are a supported but non-trivial case; if your spec splits across files with unusual reference patterns, that is where I would expect breakage first, and the material does not document the boundaries of that support. The Rust path is more constrained than the marketing suggests: it consumes nightly rustdoc JSON, and the snapshot mode exists precisely because stable toolchains cannot produce that JSON directly. That means a two-step pipeline in CI, generate the snapshot on nightly, convert it on stable, and the snapshot must be regenerated whenever the API surface changes. The MCP adapter is also newer ground: tools, resources and prompts rendered with JSON-RPC, TypeScript and Python samples is a narrower surface than OpenAPI, and the README does not describe how it handles schema evolution or versioning of MCP definitions. Finally, the release cadence is visible in the supplied data: three patch releases between mid-June and mid-July 2026, then a gap to a push in September 2026. Frequent patches on a young tool mean you should pin a version and read the release notes before upgrading.
Alternatives and the actual difference in approach
The obvious comparison is Redoc or Swagger UI for the API reference portion. Those render a spec in the browser at request time, either as a bundled script or a hosted page, and they do one thing: display an OpenAPI document. Sourcey does not render at request time at all, and it does not stop at the API reference. It also produces guides, changelog, roadmap, search index and llms.txt from the same graph. The trade is that Redoc and Swagger UI give you a live, always-current view the moment the spec changes, with no build step, whereas Sourcey requires a successful build before anything updates. For C++ specifically, the alternative Sourcey positions against is the Breathe, Exhale and Sphinx chain, which the README describes as a four-tool pipeline. Sphinx is far more mature and has a much larger ecosystem of extensions, but it needs Python, a Doxygen run, and a Sphinx configuration on top. Sourcey collapses that into one command at the cost of being a younger project with a copyleft licence. For Go, the alternative is the standard godoc tooling itself; sourcey-godoc exists as a native binary precisely so Go teams can use it without the JavaScript toolchain, but it still routes through the same rendering model.
Maintenance cost and what to verify before adopting
The maintenance surface is a sourcey.config.ts file, your source specs, and a pinned Sourcey version. There is no server to patch and no database to migrate, which is the main reason the build-time model is cheap to run. The cost sits in upgrades: patch releases arrive frequently, and because the tool normalises several unrelated formats, a change in the Doxygen or rustdoc converter can affect a project that only uses OpenAPI if the shared graph code moves. Pin the version in package.json or the Docker image tag, and read the release notes for the version you are moving to. Before adopting, verify three things against your own repository: that sourcey init correctly detects your specs and Doxyfiles, since detection is heuristic; that sourcey build resolves every $ref in your largest multi-document spec; and that the dist/ output matches what sourcey dev served, because a dev server and a build can diverge in ways a screenshot will not reveal. If your team cannot run a build in CI, Sourcey is the wrong tool.
Editorial conclusion
Adopt Sourcey if your docs must be committed artifacts you host yourself and your sources are OpenAPI, Doxygen XML, godoc, rustdoc or Markdown. Do not adopt it if you need runtime rendering, a hosted editing dashboard, or an AGPL-3.0-free dependency in a closed product. Before committing, run sourcey build against your largest spec and check two things: that every $ref resolves, and that the generated dist/ matches what sourcey dev showed you.
Community notes