# github/docs: the repository behind docs.github.com

> github/docs is the public source of docs.github.com, built with Next.js and TypeScript. It accepts Markdown content contributions only, and the README is explicit that infrastructure files are closed to outside edits.

**github/docs** — The open-source repo for docs.github.com

- Repository: https://github.com/github/docs
- Website: https://docs.github.com
- Stars: 20,914 · Forks: 68,880
- Language: TypeScript
- License: CC-BY-4.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/github-docs

## What github/docs is, and who it is actually for

This repository is the source of the site at docs.github.com. It is not a tool you install to produce your own documentation. It is the content and rendering codebase for one specific publisher, and the README frames everything around that: "GitHub's documentation is open source, meaning anyone from inside or outside the company can contribute."

The audience splits in two, and the README says so directly. GitHub employees are pointed at CONTRIBUTING.md in the docs-content repository, while open source contributors are pointed at .github/CONTRIBUTING.md in the docs repository. If you are outside GitHub and you want to correct a typo, clarify a procedure, or add a reusable snippet, this is the right repository. If you are looking for a framework to generate docs for your own API, this is the wrong repository, and nothing in the README suggests otherwise.

## The two-repository split and what the public repo will accept

The most important architectural fact is not in the code. It is that there are two repositories. github/docs is public and open to external contributions. github/docs-internal is private and is where GitHub employee contributions go. The README states that the two sync frequently and that "content changes in one are reflected in the other."

That sync has a consequence for anyone filing a pull request. A change accepted in the public repository may also need to exist in the private one, and the README notes that Hubbers might prefer to post in docs when working with a customer, but that docs has limits on the kinds of contributions it accepts "to safeguard the site and our workflows." The stated boundary is narrow: the docs repository accepts contributions to content files, meaning .md files in /content and select /data sections such as reusables. Infrastructure files, workflows, and site-building code are not open for external modification. If your fix requires touching src/ or a workflow, the public repository will not take it.

The top-level layout matches that split. content/ and data/ hold the material outsiders can edit. src/, config/, patches/, next.config.ts, eslint.config.ts and vitest.config.ts are the site itself.

## Running docs.github.com locally with Docker and Node

The repository ships a Dockerfile and a docker-compose.yaml, but read the comments before you build. The Dockerfile states it "is used solely for production deployments to Moda" and points to src/deployments/production/README.md for local building. So the compose file is not the local development path. It defines a single service named webapp that builds from Dockerfile.openapi_decorator and tags the image openapi_decorator, which is a decorator build, not the docs site.

Local development is a Node project. The package.json declares "type": "module", marks the package private, and exposes ./src/frame/server.ts as its export. The .nvmrc file pins a Node version, and the Dockerfile installs Node from the 24.x line, so check .nvmrc before installing dependencies.

```bash
git clone https://github.com/github/docs.git
cd docs
npm install
npm run debug
```

The debug script is the interesting one. It runs cross-env NODE_ENV=development ENABLED_LANGUAGES=en nodemon --inspect src/frame/server.ts, so it starts the frame server in development mode with English as the only enabled language and exposes the Node inspector. Set ENABLED_LANGUAGES to an empty string only if you also plan to clone translations, which is a separate script.

Several features are proxied or disabled unless you supply environment variables. Copy .env.example to .env and fill in what you need. ELASTICSEARCH_URL points at a local Elasticsearch service, and the file notes that when this value is unset, searches are proxied to the production Elasticsearch endpoint. HYDRO_ENDPOINT and HYDRO_SECRET control event sending, and CSE_COPILOT_SECRET plus CSE_COPILOT_ENDPOINT are described in the file as needed to auth for AI search. If you are working on content rather than search, you can leave most of these blank.

## The build, test and content scripts you will actually touch

package.json is dense with entry points, and the naming tells you which side of the repository each belongs to. Content work runs through add-content-type, all-documents and cta-builder, all of which are tsx scripts under src/content-render/scripts/. Link checking has its own script, check-github-github-links. Translation work has clone-translations, which runs a shell script, and count-translation-corruptions, which sets NODE_OPTIONS=--max-old-space-size=8192 before running, a hint that the translation corpus is large enough to need a raised heap.

The production build is simply npm run build, which the package.json defines as next build --webpack. That is the whole rendering story visible here: Next.js, webpack, TypeScript. There is a vitest.config.ts at the top level, so the test runner is Vitest rather than Jest, and eslint.config.ts indicates a flat ESLint configuration.

A practical note on the search scripts. analyze-text and the scrape script referenced in .env.example both depend on Elasticsearch, and BUILD_RECORDS_MAX_CONCURRENT defaults to 100 with a comment that you may want a lower value depending on your CPU. If you are only editing Markdown, none of this is on your path, and the local server will render your page without it.

## Where github/docs stops being the right tool

The clearest limitation is also the one most likely to waste your time: the public repository does not accept changes to infrastructure, workflows, or site-building code. If you find a rendering bug in src/frame/server.ts, you can read the code, but the README says that surface is not open for external modification. The same applies to the Next.js configuration and the deployment files.

The second limitation is the sync model. Because content lives in two repositories that sync frequently, a contributor working only in the public repository has no visibility into whether the same page was changed on the private side. The README does not document how conflicts between the two are resolved, and it does not describe a rollback path for content that has already been synced. Treat that as an unknown rather than a feature.

Third, the release history is thin relative to the activity. The most recent release listed is v1.0.1 from 2023-02-14, while the last push to the repository was on 2026-09-18. The repository is not archived, but the release tags clearly do not track the content work. If your adoption decision depends on versioned releases, this project does not give you much to depend on.

Finally, if you want a documentation generator for your own product, this is not it. There is no configuration file that points the build at arbitrary Markdown, and the content directory is structured for GitHub's own information architecture.

## github/docs compared with a wiki or a static site generator

The natural comparison is a GitHub wiki, and the difference is structural rather than cosmetic. A wiki lives beside a repository, is edited through the web interface, and has no build step, no test suite and no review gate beyond the wiki's own permissions. github/docs is a Next.js application with a TypeScript codebase, a Vitest configuration, an ESLint configuration, and a content directory that is validated by scripts such as check-content-type and check-github-github-links. Contributions arrive as pull requests and run through that tooling.

Against a static site generator such as Docusaurus or MkDocs, the difference is scope. Those tools take your Markdown and produce a site you own. github/docs produces one site, docs.github.com, and the rendering code is not packaged for reuse. The shared trait is that content is plain Markdown in a repository; the divergence is that github/docs couples that content to GitHub's own frame server, search backend and deployment pipeline, none of which are exposed as a library.

## Licence, maintenance and what a contributor should verify first

The licensing is split, and the README states it plainly. Documentation and content in the assets, content and data folders fall under Creative Commons Attribution 4.0, with the text in LICENSE. Code falls under the MIT License, in LICENSE-CODE. The package.json records the combined expression as "(MIT AND CC-BY-4.0)".

That split matters for reuse. If you copy a paragraph from the content directory into your own documentation, the CC-BY-4.0 terms apply and attribution is part of the deal. If you copy a helper from src/, MIT applies. This is a description of what the files say, not legal advice; read both licence files yourself before reusing anything.

The repository is not archived, and the last push was on 2026-09-18, so the codebase is receiving changes. The release tags do not reflect that cadence, with v1.0.1 from 2023-02-14 as the most recent entry, so pinning to a release is not a meaningful strategy here. Upgrade cost for a contributor is mostly local: Node version, dependency install, and whichever environment variables your task needs. There is no versioned upgrade path to plan for, because content changes flow through the sync between the two repositories rather than through releases.

## Conclusion

Adopt github/docs as a contribution target if you want to fix or extend GitHub's public documentation; the README directs open source contributors to CONTRIBUTING.md in the docs repository and says the accepted surface is .md files in /content plus select /data sections such as reusables. Do not treat it as a documentation generator you can point at your own product, and do not expect to modify workflows or site-building code here. Before you open a pull request, check whether the page you want to change also exists in github/docs-internal, because the README states the two repositories sync frequently and that internal contributions should usually go to docs-internal.

## FAQ

### Is GitHub Docs free?

The repository is open source and the README says anyone from inside or outside GitHub can contribute. Content is licensed CC-BY-4.0 and code is licensed MIT, so both the documentation and the site code are free to read and reuse under those terms.

### What is GitHub Docs?

It is the open-source repository behind docs.github.com, written in TypeScript and built with Next.js. The README describes it as GitHub's documentation, open for contributions from anyone.

### How do I use github/docs?

External contributors edit .md files in the content directory and select data sections such as reusables, then open a pull request. The README points open source contributors at .github/CONTRIBUTING.md in the docs repository for the quick-start summary.

### How do I access github/docs?

The repository is public at github.com/github/docs, and the published documentation it produces is at docs.github.com. The README lists separate contributing guides for GitHub employees and for open source contributors.

### What is the difference between github/docs and a wiki?

github/docs is a Next.js and TypeScript application with a content directory, a Vitest test configuration and link-checking scripts, and changes arrive as pull requests. A wiki is edited in place with no build step or review tooling of that kind.

## Sources

- [github/docs on GitHub](https://github.com/github/docs)
- [License: CC-BY-4.0](https://github.com/github/docs/blob/main/LICENSE)
- [Project website](https://docs.github.com)
- [README](https://github.com/github/docs/blob/main/README.md)
- [Releases](https://github.com/github/docs/releases)

---

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