# mongodb/docs: the source behind the MongoDB manual and its doc tooling

> The mongodb/docs repository holds the MongoDB documentation published at mongodb.com/docs, along with the TypeScript lint tools and GitHub Actions that keep it consistent. Contributions are governed by a separate contributor agreement, and the prose is published under a Creative Commons licence rather than an open source one.

**mongodb/docs** — The MongoDB Documentation Project Source.

- Repository: https://github.com/mongodb/docs
- Website: https://www.mongodb.com/docs/
- Stars: 778 · Forks: 1,700
- Language: TypeScript
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/mongodb-docs

## The published manual and its build inputs share one tree

The mongodb/docs repository is described as the MongoDB Documentation Project source, and the content it produces is the documentation served at mongodb.com/docs. The repository layout shows a much larger surface than a prose folder.

Content lives in several parallel directories. There is content/ and content-mdx/, the latter pointing at MDX, the JSX-flavoured Markdown used by modern documentation tooling, plus ext-source/ for externally sourced material, deprecated_examples.json for examples that are on the way out, and a platform/ directory that presumably varies content per deployment target. The NoindexEntireSource.sh script and the context7.json file suggest the repository is also consumed by tooling beyond the website itself, with the first controlling indexing and the second describing the project to a machine reader.

The supporting scripts at the root are the connective tissue. setup-docs.sh prepares a local docs environment, lint-docs.sh runs the linters, repo_sync.py synchronises with related repositories, and there is a .drone.yml for continuous integration alongside a requirements.txt. A vale.ini file points at Vale, the prose linter, and .copier/ and .husky/ indicate templated project generation and a git hook for checks before commit.

There is also a code-example-tests/ directory, which is the part with the most value for a reader who cares about documentation accuracy: it implies the code samples in the manual are executed rather than trusted.

The directory names .augment/, .claude/ and .opencode/ show that AI-assisted authoring and review tooling has been adopted in the workflow, and the CLAUDE.md file at the root is likely where the conventions for those tools are written down.

## The lint tools follow a flat, prefixed, single-package convention

The .github/ directory holds the documentation automation tools, and the README spells out the conventions for them in unusual detail, which suggests they were settled after some churn.

The structure guideline in the README shows the shape:

```
.github/
├── lint-docs/          # Doc linters (flat structure)
│   ├── seo-lint-cli.ts
│   ├── seo-lint-rules.ts
│   ├── 404-lint-cli.ts
│   ├── package.json
│   └── tsconfig.json
├── ai-reviewer/        # AI style reviewer
└── workflows/          # GitHub Actions
```

Three rules govern how new tools are added. Related files go directly in one folder rather than in subfolders, so a folder does not turn into a directory tree. File names carry a prefix, with seo-lint- and 404-lint- given as the examples, and the stated reason is better IDE tab visibility, which is a small detail that turns out to matter when several tools share a flat folder. Each tool folder gets one shared package.json rather than one per script.

When adding a tool, the instructions are to create .github/<tool-name>/, use descriptive file prefixes such as tool-name-cli.ts and tool-name-rules.ts, and include package.json, a tsconfig.json and a brief README.

The tools themselves are TypeScript, which matches the primary language recorded for the repository. The two named linters target search engine optimisation and broken links, and the 404 linter in particular is the one that catches a documentation site in a state where a page that used to exist no longer resolves, which is a common failure for a manual with thousands of pages.

## Contributing is gated by an agreement and a pull request

The contribution path is short and formal. The project is governed by the terms of the MongoDB Contributor Agreement, and the README asks that you sign it if you have not already done so, then fork the repository on GitHub and issue a pull request.

That sequence matters, because the agreement is a precondition rather than a formality to be signed later. The project is run as a documentation programme with legal terms attached, and the content it publishes is licensed separately from the tooling.

For issues there is a different channel. The README points to the Rate this page feedback widget on the right side of documentation pages, and asks you to leave a comment there. The intent is that reader feedback about a specific page goes back to that page rather than into an issue tracker, which keeps the tracker for real repository problems.

The community channels listed are a Slack channel for the project and a Twitter account, and a code of conduct is referenced in the repository, though the file is not visible in the top-level listing shown here. A contributing guide and a security policy are also referenced in the README.

If your goal is to fix a typo in an article, this path is slower than it might look, because the agreement comes first. If your goal is to understand how the documentation is organised, the repository itself is the answer, and no contribution is required to read it.

## Prose under Creative Commons, tooling under an unstated licence

The licensing picture has two halves, and only one of them is spelled out. The README states that all documentation is available under the terms of a Creative Commons licence, and the link points at the attribution, non-commercial, share-alike 3.0 licence.

That is a meaningful restriction for a technical manual. You can copy the text and adapt it, but the share-alike condition means a derived document has to carry the same terms, and the non-commercial clause rules out some uses outright. The net effect is that the documentation is easy to reuse for learning and internal reference, and less easy to fold into a commercial product or a competing manual without thinking about the terms.

The tooling sits outside that statement. The repository licence is recorded as unknown, and the README does not have a separate section describing the terms for the lint scripts, the AI reviewer or the workflow files. For a project that is inviting outside contributions to those tools, that gap is worth raising as an issue.

The distinction matters practically. If you want to quote a MongoDB tutorial in a course, the documentation licence is what governs it. If you want to reuse the SEO linter or the 404 linter in your own documentation pipeline, that is the tooling side, where the answer is not stated in the files this repository documents.

## An active documentation tree with no releases to pin

The repository is not archived, and the last push was on 2026-10-19, so the tree is being worked on constantly. There are no GitHub releases, which is the normal arrangement for a documentation repository where the published artefact is the website rather than a versioned package.

The release model is different in kind from a library. A reader never installs a version of the MongoDB manual, they read the current version, and the URL is stable while the content moves underneath it. That has consequences for anyone who wants to cite or archive documentation, because there is no tag to point at and no way to retrieve the text as it read on a given date from the repository alone.

The per-page feedback widget suggests the project treats the live site as the artefact and the repository as the means of producing it. The presence of deprecated_examples.json points to the same housekeeping concern from the other side, since a manual that spans many product versions accumulates examples that no longer apply.

For a contributor, the practical questions are about conventions rather than infrastructure. Vale and the custom linters define the prose style, the ai-reviewer folder suggests automated style review is part of the pull request path, and the code-example-tests directory implies your sample code may be run. The GitHub Actions workflows in .github/workflows/ are what tie those checks together.

## Conclusion

mongodb/docs is worth reading if you need to see how a documentation set at this scale is structured, linted and reviewed, since the automation folder shows a working answer to consistency problems that smaller projects end up reinventing badly. It is not a place to contribute if you want a code change merged, because the process runs through a contributor agreement and a fork and pull request, and it is not a source of reusable components either, since the tools are scoped to one documentation set. Before you act on any of it, verify three things yourself: that you have signed the MongoDB Contributor Agreement, since that is a stated precondition for contributing, that the Creative Commons attribution, non-commercial and share-alike terms on the prose are acceptable for your intended use, and that a separate repository licence applies to the tooling, because the repository licence field is recorded as unknown.

## FAQ

### How do I contribute to the MongoDB documentation?

Sign the MongoDB Contributor Agreement first, then fork the repository on GitHub and issue a pull request. The README states the agreement is a precondition for contributing, and the project is governed by its terms.

### How do I report an error in a MongoDB documentation page?

Use the Rate this page feedback widget on the right side of the documentation pages and leave a comment. The project asks readers to send page-specific feedback through that widget rather than the issue tracker.

### What can I reuse from the mongodb/docs repository?

The documentation is published under a Creative Commons attribution, non-commercial, share-alike 3.0 licence, which covers reuse and adaptation of the prose under those conditions. The licence of the tooling in .github/ is recorded as unknown, so check before reusing the lint scripts.

### What automation tools does the MongoDB docs repository include?

The .github/ directory holds lint-docs with TypeScript SEO and 404 linters, an ai-reviewer for style review, and GitHub Actions workflows. The convention is a flat folder per tool, prefixed file names, and one shared package.json in each tool folder.

## Sources

- [Issues](https://github.com/mongodb/docs/issues)
- [mongodb/docs on GitHub](https://github.com/mongodb/docs)
- [Project website](https://www.mongodb.com/docs/)
- [README](https://github.com/mongodb/docs/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mongodb-docs