langchain-ai/docs: the build pipeline behind docs.langchain.com

What langchain-ai/docs actually is, and who should clone it

This repository is the documentation build pipeline for LangChain projects. The site it feeds is docs.langchain.com, which the README describes as the docs home centralizing LangChain, LangGraph, LangSmith, and LangChain Labs (Deep Agents, Open SWE, Open Agent Platform), hosted on Mintlify. The source of truth for page content lives in src/, split into langsmith/ for LangSmith docs and oss/ for LangChain, LangGraph, Deep Agents, and integrations docs.

The audience is narrow and specific. If you are fixing a typo, adding a how-to guide, or correcting a code sample that appears on docs.langchain.com, this is the repository you open a pull request against. The README points contributors at a contributing guide that explains the documentation types and their writing and quality standards, and says changes follow a PR workflow where all tests must pass before merging.

It is not the repository for API reference. The README is explicit that reference.langchain.com hosts generated API reference for LangChain, LangGraph, LangSmith, and integration packages, and that this site is not built from this repository, with no reference build scripts or output living here. If your problem is a missing class page or a broken signature in the Python or JavaScript reference, editing MDX here will not fix it. The README routes those reports to a reference documentation issue template on this repo so maintainers can forward them.

There is also a chat.langchain.com assistant that answers questions about LangChain documentation. That is a separate surface again, and the README does not describe it as part of this build.

The src to build split, and why editing /build is a dead end

The pipeline is a two-directory arrangement. Source files sit in src/ as .mdx, and build artifacts land in build/. Mintlify deploys from build/, which is generated by preprocessing logic in the pipeline/ directory. The README puts the rule in a callout: never edit /build directly. Anything you change there is overwritten on the next build, so a pull request touching it is wasted work.

The repository layout the README prints lists build/ as built docs (do not edit), packages.yml as package metadata covering indexes, tables and downloads, pipeline/ as the build pipeline source, scripts/ as helper scripts, src/ as the editable content, tests/ for pipeline tests, the Makefile, and pyproject.toml for dependencies. Navigation and site settings are not scattered across pages: they live in src/docs.json, which configures the Mintlify site navigation and settings, and the README defers to Mintlify's own navigation documentation for syntax.

File formats matter more than usual here. Plain .md and .mdx files are standard documentation content. Snippets live in src/snippets/ and are reusable MDX importable into multiple pages, but the README warns that snippets undergo special link preprocessing and that you should be careful about path segments when writing links inside them. Jupyter notebooks are converted to markdown during build, and the README states they are not recommended for new content, adding that a PR will likely be rejected if you add one unless a maintainer asked for it. Images and other assets are copied into the build directory.

One consequence worth stating plainly: because navigation is centralized in src/docs.json, adding a page is not just a matter of creating a file. A page that exists in src/ but is absent from that config will not appear in the site navigation.

Installing the pipeline and previewing a page locally

The README gives a four-step local preview. Clone the repository, change into it, install dependencies, and start development mode. The Makefile wraps the same targets the README names.

git clone https://github.com/langchain-ai/docs.git
cd docs
make install
make dev

make install is documented as installing all dependencies and linking authoring skills, and make dev starts development mode with file watching and live rebuild. The dev target itself runs npm install and then PYTHONPATH=$(CURDIR) uv run pipeline dev, so a working uv and Node setup is assumed before the preview comes up. The README also notes that make skills links .agents/skills into .claude/skills for Claude Code, that it runs as part of make install, and that you re-run it after new skills are added.

Before opening a pull request, the targets that matter are the checks the README lists. make test runs the test suite, make lint checks code style and formatting, make format auto-formats, and make lint_md lints markdown files with make lint_md_fix as the fixing variant. Link integrity has its own pair: make broken-links checks for broken links, and make broken-links-with-anchors adds anchor checking on top.

make test
make lint_md
make broken-links-with-anchors

What you should see is a passing test run, markdown lint output with no complaints about the files you touched, and a link check that reports no broken links or anchors. The README also documents a docs CLI installed as uv run docs, with subcommands for migrating content from other documentation systems: docs migrate <path> for MkDocs markdown and notebooks, docs migrate-docusaurus <path> for Docusaurus markdown and notebooks, and docs mv <old_path> <new_path> to move files and update cross-references. Each supports --dry-run, and the migrate commands accept --output to choose a destination instead of editing in place.

The export target, and where the toolchain stops cooperating

The most constrained part of the Makefile is export, which produces an offline zip through Mintlify. Its comments spell out a stack of preconditions. It requires a recent mint CLI with the mint export subcommand, Node LTS 20 or 22 with Node 25 and above unsupported, and an Enterprise Mintlify plan. The target checks for the binary, greps mint help for mint export, and aborts with an upgrade instruction if the subcommand is missing. It then reads the Node major version and refuses to continue at 25 or higher, telling you to switch to Node 20 or 22, reinstall mint for that Node version, and retry.

The export target also has to run from build/, because docs.json paths are written as oss/python/... and oss/javascript/... while sources live under src/oss/... until the pipeline emits build/oss/{python,javascript}/. The default output when run from build/ is build/export.zip, overridable through MINT_EXPORT_ARGS with a matching EXPORT_ZIP for htmltest. There is also an htmltest-mint-export.yml at the repository root and htmltest targets in the Makefile's .PHONY list.

This is the clearest case where the project is the wrong tool. If what you want is a downloadable or offline copy of the LangChain documentation, the path exists but is gated: an Enterprise Mintlify plan plus a pinned Node major version. A contributor fixing a page never touches this target. A reader who wants a PDF or a zip of the docs is not the audience this repository is built for, and the README does not present an alternative offline route.

The README's troubleshooting section acknowledges that the toolchain does fail in practice. It documents a docs dev not working or running case, a Mintlify .venv parsing error, a warning that a page does not exist, and general Mintlify errors. The README does not document rollback of a build, and it does not describe what a partial or failed build leaves in build/.

How this differs from building docs inside a framework repo

The obvious alternative is the pattern most Python projects use: keep documentation next to the code, so the docs for langchain-anthropic live in the langchain-anthropic repository and the docs for LangGraph live in the LangGraph repository. That approach keeps a code change and its documentation change in one pull request and one review, and it means the person writing the page is usually the person who knows the API.

The langchain-ai/docs repository inverts that. Documentation for LangChain, LangGraph, LangSmith, Deep Agents and integrations is consolidated into a single MDX tree under src/, built by a shared Python pipeline and deployed as one Mintlify site. The trade-off is visible in the layout: the dependency list in pyproject.toml includes langchain[mcp], langgraph, langsmith, langchain-anthropic, langchain-openai, langchain-google-genai, deepagents and others, which is what you would expect if the pipeline executes or validates samples for many of those products in one place. The cost is that a documentation fix and the code it describes can land in different repositories, with different review queues and different release timing.

The API reference split is the same trade-off taken further. Generated reference for Python and JavaScript is built and deployed outside this repo, so a documentation contributor cannot fix a generated signature here, and a reference issue must be routed by maintainers through the issue template. Consolidation buys one navigation file, one build, and one set of writing standards across the whole product family. It costs locality between code and docs.

If your team maintains a single library and its docs, the in-repo pattern is simpler and this repository's structure will look like overhead. If you maintain several related products that must present as one documentation set, the consolidation is the reason the structure exists.

Maintenance, licensing, and what a contribution costs to keep

The repository is not archived, and the last push was on 2026-09-15. The project is licensed MIT, and the LICENSE file sits at the repository root. MIT is permissive, so reusing the MDX sources or the pipeline code carries few obligations beyond keeping the copyright and permission notice with substantial portions; that is a description of the licence text, not legal advice, and the README does not discuss trademark or brand usage for the LangChain name or the docs content itself.

Upgrade cost concentrates in two places. The first is the Python environment: pyproject.toml requires Python >=3.13.0,<4.0.0 and sets a uv required-version floor of >=0.9.26, with a comment explaining that a bare version would be read as == and break contributors on a newer uv, and that the exact version for CI lives in .github/actions/uv_setup while local development uses .mise.toml. That is a deliberate split, and it means a CI failure and a local failure have different sources. There is also an override-dependencies entry in the truncated tool.uv section, so dependency resolution is being managed rather than left to defaults.

The second is the Node and Mintlify side: the export target hard-fails on Node 25 or above and requires the mint CLI to expose mint export, which is why the Makefile instructs you to reinstall mint globally when the subcommand is missing. The repository pins a Node version through .node-version and uses pnpm-lock.yaml alongside package-lock.json, with the package.json declaring a single dependency, @langchain/docs-sandbox. The pipeline itself is a Python package, with docs = "pipeline.cli:main" registered as the console script, so the docs command and the pipeline share one entry point.

For a contributor, the recurring cost is running the checks the README lists before every pull request, plus the time to keep uv and Node within the ranges the repository expects. The README does not state a deprecation policy, a support window, or a schedule for when old pages are removed.

Editorial conclusion

Adopt langchain-ai/docs if you are writing or fixing pages that appear on docs.langchain.com: clone it, run make install and make dev, and edit only under src/, since the README states that /build is generated and must never be edited directly. Do not adopt it if you want the generated API reference, which the README says is built and deployed outside this repository, or if you want an offline archive of the docs, because the export target requires an Enterprise Mintlify plan and Node 20 or 22. Before you invest time, verify three things: that uv satisfies the required-version floor of >=0.9.26 in pyproject.toml, that your change belongs in src/ rather than in src/snippets/ (where link preprocessing behaves differently), and that the page you are editing is not a Jupyter notebook, since the README states notebooks are not recommended for new content and PRs adding them will likely be rejected.

Frequently asked questions

Official sources

1. Issues
2. langchain-ai/docs on GitHub
3. License: MIT
4. Project website
5. README