docmd: one Markdown tree, compiled into a site, an index, and agent-readable context
Documentation compiler for humans and machines. One Markdown source to website, search, AI context, and knowledge formats together.
At a glance
- What is it?
- docmd is a TypeScript documentation compiler that turns a folder of Markdown into a static SPA, an offline search index, llms.txt files, OKF knowledge bundles and an MCP endpoint in a single build. The zero-config start is real, but the 0.9 line is where most of the machine-facing output lives, so version pinning matters.
- Who is it for?
- Adopt docmd if you already have a Markdown tree and you want the machine-readable outputs (llms.txt, OKF bundles, the MCP endpoint) produced by the same command that produces the site, and if you are willing to pin an exact 0.9.x version because the assistant and OpenAPI surfaces are still moving release to release.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day 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 specific gap docmd is aimed at: documentation that has to be read by software as well as people
A conventional static site generator ends its job when it writes HTML. Everything a language model, a retrieval pipeline or a coding agent needs is then bolted on afterwards: a hand-maintained llms.txt, a separate embedding job, a scraper that re-parses the rendered pages. docmd's premise is that all of those outputs share one input, the Markdown tree, so they should be produced by one build rather than by four pipelines that drift apart.
The README frames this as an ecosystem rather than a site: the same source is said to yield a static website, a search index, llms.txt, OKF bundles, sitemap and SEO metadata, robots.txt and Open Graph tags, an MCP server, and an optional Cloud Relay. That list is the product. If you only want HTML, docmd is a heavier answer than you need.
The audience is therefore narrower than "anyone writing docs". It fits teams that already keep documentation as Markdown in a repository and that have a second consumer in mind: an internal chatbot, a RAG pipeline, or an IDE agent such as Cursor or Claude Code that should be able to query the docs directly. The README states the project treats AI as a first-class way to consume documentation without replacing the documentation itself, which is a reasonable description of the design intent.
What the build actually does, based on the pipeline shown in the README
The mechanism is a compiler with named stages, and the quick-start output in the README prints them. The build reads a source directory (docs/ by default) and a config file at ./docmd.config.json, then runs a data-indexing phase: syncing git metadata, building the search index and RAG embeddings across multiple versions, and generating AI Assistant RAG context. A publishing phase follows: robots.txt, .nojekyll for GitHub Pages, sitemap, llms.txt context files, and OKF bundles. The README's sample run reports an initial build of 1.2s on that machine, with two versions and seven locales configured.
Two details in that output are worth pulling out. First, versioning and localisation are inputs to the index, not afterthoughts: the sample shows the search and embedding stage running multi-version, so an old release line can remain queryable. Second, the dev server watches three separate paths (source, config, assets), which means editing docmd.config.json restarts parts of the pipeline rather than only triggering a page rebuild.
Navigation is derived from the file structure. The README states no config file, no frontmatter and no framework are required to get a working site, and that the output is static HTML with minimal vanilla JavaScript, with pages navigating as an SPA. The search index is described as offline full-text, requiring no cloud service. That combination is the architectural bet: ship plain files, do the index work at build time.
Getting it running: three commands and one config file
The README gives a no-install path first. From any folder containing Markdown, npx @docmd/core dev starts the development server, which the README says opens at http://localhost:3000. The sample banner also shows a network address, so the dev server binds beyond loopback by default, which is convenient on a LAN and something to be aware of on shared networks.
To produce a deployable site, npx @docmd/core build writes a static SPA that the README says is ready for Vercel, Cloudflare Pages, Netlify, GitHub Pages or any static host. Node.js 18 or newer is the stated requirement.
There are two other installation routes in the README. A global install via npm install -g @docmd/core or pnpm add -g @docmd/core exposes the docmd binary, so docmd dev and docmd build work without npx. A container image is published at ghcr.io/docmd-io/docmd:0.9.0 and run with docker run -p 3000:3000 ghcr.io/docmd-io/docmd:0.9.0; the README explicitly advises pinning a version for reproducible builds, which is the right instinct given the release cadence.
The configuration surface named in the material is thin: docmd.config.json is the file the watcher looks for, and the README says it is optional for a basic site. Beyond that, the README does not enumerate config keys, so I cannot tell you which keys control versions, locales or the AI provider. Those are documented at docs.docmd.io, not in the repository README, and you should read them there rather than infer them.
The AI surfaces: an assistant plugin, an MCP endpoint, and a hosted relay
Three separate things sit under the AI label, and conflating them is easy.
The first is @docmd/plugin-ai, described as a RAG-powered chat grounded in your documentation. The README says it can use your own API key or a local AI provider, and mentions AIPlug as the layer providing access to a wide range of providers. The second is the MCP server: docmd mcp, which the README says exposes your docs to AI agents over stdio so tools like Cursor and Claude Code can query them. This is the most concrete of the three, because stdio MCP is a defined transport and the client side is already built into those editors. The third is Cloud Relay, a hosted service at cloud.docmd.io that the README positions as a way to enable the AI Assistant on static documentation without running your own AI backend.
The trade-off is visible in that third option. A static site with a hosted search relay is operationally simple, but it means documentation content leaves your infrastructure when a user asks a question. For public API docs that is unremarkable. For internal runbooks or anything under an NDA, the local-provider or own-key path is the one to evaluate, and the README does not describe what the relay stores or for how long. Treat that as an open question to resolve before enabling it.
Where docmd is the wrong tool
The clearest limitation is the ecosystem. The README's comparison page is against Docusaurus, Mintlify and others, and the topics list includes plugins and themes, but nothing in the supplied material describes a third-party plugin registry, a theme marketplace, or an inventory of community extensions. Docusaurus has years of that; docmd has a plugin naming convention (@docmd/plugin-ai) and a promise of extensibility. If your requirement is "there is already a plugin for this", docmd is not the safe pick.
The second limitation is content model. A zero-config generator that derives navigation from the file tree is excellent for prose and awkward for anything that wants to be a component. If your current docs embed interactive React components, live API explorers written as JSX, or MDX with imports, the README gives no indication that this content model is supported. The OpenAPI topic appears in the repository topics and in two release titles, but the README excerpt does not describe how an OpenAPI specification is consumed, so I cannot confirm whether it generates reference pages or only indexes a spec file.
The third is release maturity. The 0.9 series is the current line, and the three most recent releases in the material are dated within roughly three weeks of each other, each shipping assistant or OpenAPI changes. That is an actively moving surface. The README's own advice to pin a version for reproducible builds applies to npm installs too, not just Docker.
Compared with Docusaurus: derived structure versus declared structure
Docusaurus and docmd solve overlapping problems with opposite defaults. Docusaurus asks you to declare the site: a sidebar configuration, a plugin array, a docs plugin instance, React components for anything custom. That declaration is the cost of entry and the source of its flexibility. docmd inverts it. The README states navigation is generated from the file structure with no config file and no frontmatter required, so the directory tree is the sidebar. You give up layout control you did not ask for and gain a build that works on an existing Markdown folder without a migration.
The second difference is the output set. Docusaurus produces a site, and the AI-facing artefacts are add-ons you assemble. docmd's README claims the search index, llms.txt, OKF bundles and the MCP server come out of the same build as the site. The claim worth testing on your own content is whether that coupling holds when your docs are large, since the README's 1.2s figure comes from a sample project whose size is not stated. If you are choosing between the two, the decision is less about features than about whether you want a declared site model or a derived one, and whether the machine-readable outputs are a requirement or a nice-to-have.
Licence, maintenance and what upgrading costs you
docmd is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own documentation content, and it imposes no requirement to publish modifications. This is a description of the licence text, not legal advice; if you are redistributing docmd inside a product, have your own counsel read the LICENSE file rather than this paragraph.
Maintenance cost is dominated by the release cadence. The material shows 0.9.3, 0.9.4 and 0.9.5 landing between 19 August and 8 September, with titles naming offline Mermaid, OpenAPI and assistant changes. A project moving that fast will occasionally change behaviour in areas you depend on. The mitigation is the one the README already recommends: pin an exact version. In practice that means npm install -g @docmd/core@0.9.5 rather than a floating range, and a fixed image tag such as ghcr.io/docmd-io/docmd:0.9.0 in your deployment rather than latest.
There is a second, quieter cost. Because the search index and RAG embeddings are produced at build time, a full rebuild is not a trivial copy step. The README's own banner shows the indexing stage running across versions and locales. Adding a locale or a version line is therefore a change to the index, not just to the page tree, and you should expect build time to scale with the product of documents, versions and locales rather than with documents alone. The material does not give figures for that scaling, so measure it on a copy of your real documentation before you commit to the multi-version layout.
Editorial conclusion
Adopt docmd if you already have a Markdown tree and you want the machine-readable outputs (llms.txt, OKF bundles, the MCP endpoint) produced by the same command that produces the site, and if you are willing to pin an exact 0.9.x version because the assistant and OpenAPI surfaces are still moving release to release. Do not adopt it if you need a mature plugin ecosystem with independent third-party themes, or if your docs are already committed to a component-based framework and you cannot rewrite MDX. Verify three things before you commit: that your Node runtime is 18 or newer, that the config keys you intend to set actually exist in the version you pin, and that your chosen AI provider path (local provider, your own API key, or Cloud Relay) is acceptable for the content in your repository.
Community notes