Zudoku: API documentation you can drop into a page with one script tag

The pitch is a documentation framework, not a generator

Zudoku, pronounced zoo-doh-koo, is an open-source, highly customizable API documentation framework for building quality developer experiences around OpenAPI and, soon, GraphQL documents.

The word framework is doing the work here. A generator takes a schema and emits a fixed site, and you get what the generator's author decided. A framework gives you a set of composable pieces, and the readme lists what it thinks a good one looks like: free and open source, OpenAPI powered, extensible with plugins, easy to set up and blazing fast to work with, and easy to maintain.

The feature list is short. Generate documentation from a single or multiple OpenAPI schemas. Create MDX pages for anything you want to document, which is the escape hatch for the parts of your product that are not an API, onboarding guides, concepts, changelogs. Integrate your users with authentication via OpenID or OAuth2. Let users test their API calls using the integrated playground, which includes authentication, so the try-it button works with the same credentials your readers have. And dark mode.

That playground with authentication is the feature that separates this from the usual static OpenAPI renderer. A reader can authenticate as themselves and issue a real request against a real endpoint from the documentation, which turns reference documentation into something a developer can actually use without leaving the page.

The framework is TypeScript, the licence is MIT, the homepage is zudoku.dev, and the recent releases are v0.93.0 from 2026-10-13, v0.92.0 from 2026-10-08 and a prerelease v0.0.0-z3bbc57a4 tagged as the upcoming release on the same day as v0.93.0. The last push was on 2026-10-19.

Two ways to run it, and the CDN route is unusual

There are two installation paths, and the second one is worth a close look because it is not how documentation tools usually work.

The first is the CLI. You can use the CLI to generate a new project, and the quick start is one command:

npm create zudoku@latest

That gives you a project you own, with your own build, your own deployment and your own configuration.

The second is standalone via CDN. The readme says you can use the CLI to generate a new project or use it standalone via CDN as a React component, and the instructions are to add the package and styles to your head and pass the URL of your API schema to the data-api-url property:

<!doctype html>
<html>
  <head>
    <title>Zudoku Demo</title>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

    <link rel="icon" type="image/svg+xml" href="https://cdn.zudoku.dev/logos/favicon.svg" />
    <script type="module" src="https://cdn.zudoku.dev/latest/main.js" crossorigin></script>
    <link rel="stylesheet" href="https://cdn.zudoku.dev/latest/zudoku.css" crossorigin />
  </head>
  <body>
    <div data-api-url="https://api.example.com/openapi.json"></div>
  </body>
</html>

There is no build step, no node_modules, no framework. A script tag, a stylesheet and a div with the schema URL in a data attribute, and the documentation renders. That is a genuinely different proposition from the create-a-project-and-deploy-it approach, and it is what makes the framework usable inside an existing site rather than only as a site of its own.

The trade is the one you would expect. With the CDN route you do not control the version, because the URL points at latest, and you get whatever the framework ships. With the CLI you control everything and own the build.

For the non-code reading, the readme points at a live demo where you can test Zudoku with your own OpenAPI document, and there are working examples for the Rick and Morty API, the Swagger Pet Store API and Zuplo's own API documentation.

The example templates, and what the plugin system is for

The examples directory is the best documentation of the plugin system, because each example is one plugin or one configuration approach isolated in a directory.

There are twenty of them. with-auth0 demonstrates the Auth0 plugin for authenticating users in the docs. many-apis is using more than one OpenAPI document with Zudoku. with-config is a barebones config ready to set up however you like, and with-vite-config is the advanced version that uses Zudoku with your own Vite config. with-base-path covers hosting under a subpath, and with-openapi-json and with-openapi-yaml are the two ways of pointing at a schema. There are also examples for a mermaid diagram renderer, an Algolia search integration, a GraphQL example, an API identity plugin, an API key service, Firebase and Supabase authentication, AWS Lambda server side rendering, Cloudflare server side rendering, and two Zuplo specific ones, cosmo-cargo and zuplo-monetization.

That list is the clearest statement of the extension surface. The framework is composable through plugins that plug into specific points, and the examples show the common ones: bring your own identity provider, bring your own search, bring your own schema source, and render the site wherever your infrastructure already runs.

There is also a getting started templates table in the readme, which links to four of the examples directly: many-apis, with-auth0, with-config and with-vite-config.

The use cases section widens the frame. Zudoku is described as a flexible and highly customizable framework that can be used to create standalone documentation websites, OpenAPI powered API references, a developer portal with documentation, a fully functional API reference for testing and authentication support for your user accounts, and internal documentation.

The developer portal case is the one that goes beyond documentation, because it is a portal with working authenticated API testing. That is the same feature as the playground, but framed as the product rather than the detail.

A monorepo with a bundle size budget

The repository is an Nx monorepo, and the root package.json shows how it is put together.

The build runs across all packages with nx run-many. The checks are layered: biome lint, then oxfmt --check for formatting, then a node script called check-admonitions that appears to police wording in the docs and site copy, which is an unusual and telling inclusion. The fix script runs biome lint --write and the formatter together.

The test setup runs vitest with the typecheck flag, with a coverage variant, and there is a separate e2e suite with Playwright. There is a size-limit configuration, and the budget it sets is worth noticing: the entry client chunk of one example, cosmo-cargo, is limited to 215 KB.

A hard size budget in a documentation framework is a statement of intent. The alternative for most users is a bundle they load but never read, and a framework that renders a large OpenAPI document has a real risk of shipping a megabyte of JavaScript to a page that is mostly text. Putting a number in the build is how you keep that from happening silently.

The tooling is otherwise modern and opinionated: pnpm 11.6.0 as the package manager, Node 22.22.0 or newer, lefthook for git hooks, TypeScript from a catalog, and the standard trimmings.

The release process is also automated in an interesting way. Instead of a local script, the release scripts trigger a GitHub workflow with a release type of prerelease or minor, so the publish path runs in CI. The prerelease tag format, v0.0.0-z3bbc57a4, with a commit hash in it, is the mark of a system that publishes continuous builds of a monorepo where not every package has a meaningful version.

The motivation, and the shape of the project

The readme explains why the project exists, and the reason is worth understanding because it tells you what the maintainers care about.

At Zuplo, they could not find an open-source solution that met their high standards for both trustworthiness and programmability, so they decided to create their own. And since no one chooses Zuplo solely because of their documentation, they felt good about open-sourcing this tool and making it easy for anyone to self-host.

The final line is the important one: they hope that if you use it, you will think fondly of Zuplo, and one day, when you are looking for a gateway or API management product, you will consider them as a vendor to evaluate. That is a company building a documentation framework as a recruiting tool, and it explains several of the design choices. The openness is not an afterthought, it is the point, and the CDN component exists so the tool can be adopted without anyone having to evaluate Zuplo as a vendor.

The readme also states the guarantee plainly: Zudoku will always be open-source, and it will always be free. And the opening line of the whole readme is the argument in one sentence: API documentation should always be free.

The repository layout supports that framing. There is an llm directory, which suggests some provision for machine-readable documentation output, a graphql.config.yml alongside the OpenAPI tooling, an e2e directory, a docs directory, a patches directory, and an .env.example with a log level and an internal development flag. There are also CLAUDE.md and AGENTS.md files and a .cursorrules file, which is the current convention for shipping repository guidance to coding assistants.

The overall shape is a commercially backed open-source project with a permissive licence, an active release cadence, and a design centre that treats both self-hosting and vendor neutrality as requirements rather than nice to have.

Editorial conclusion

Adopt Zudoku if you publish an OpenAPI document and want interactive documentation with a try-it playground, and you would rather self-host a documentation site than have your API vendor generate it for you. Do not adopt it expecting GraphQL support today, because the readme says GraphQL documents are soon, and note that the version line is pre-1.0 with a prerelease tag in circulation. Before you commit, try your own OpenAPI document on the hosted demo, and decide between the generated project and the CDN component, because that choice determines whether you own the build and the deployment.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. zuplo/zudoku on GitHub