godotengine/godot-docs: the reStructuredText source behind Godot's manual

What godot-docs actually is, and who ends up needing it

This repository is not the Godot engine. It is the source of the manual that sits at docs.godotengine.org, written in reStructuredText and parsed by Sphinx. The README is explicit about that pipeline: the reST files "are meant to be parsed with the Sphinx documentation builder to build the HTML documentation on Godot's website."

That narrows the audience considerably. If you are a game developer looking up how a node behaves, you want the rendered site, not this repository. If you are a technical writer fixing a wrong sentence in the manual, adding a tutorial, or maintaining a translation, this is the repository you work in. The same applies to anyone who wants to build the docs locally to check a change before opening a pull request.

The repository is large in scope even though it contains no engine code. The top level holds about/, classes/, community/, engine_details/, getting_started/, and tutorials/, plus the Sphinx configuration in conf.py and the extension and template directories. The classes/ folder is the exception worth remembering: those files are derived from Godot's main source repository, which means the class reference you read on the website is generated material living inside the docs repository rather than hand-written prose.

How the reST sources become the site you read

The data flow is conventional Sphinx. reStructuredText files plus conf.py go in, an HTML tree comes out, and the theme layer is the default sphinx_rtd_theme with customizations stored in _static/. The README notes that the site switches between light and dark automatically based on browser or OS preference, which is a theme-level behaviour rather than anything authors configure per page.

requirements.txt pins the toolchain rather than floating it: sphinx==8.1.3, sphinx_rtd_theme==3.1.0, and pygments==2.21.0, followed by a small set of extensions. Each extension maps to something visible in the rendered output. sphinx-tabs renders code blocks in different languages as tabs, sphinx-copybutton adds a copy button to code blocks, sphinx-notfound-page supplies a custom 404, sphinxext-opengraph writes Open Graph tags into the HTML head, and sphinxcontrib-video provides the video directive used to embed videos.

The Makefile is a thin wrapper over sphinx-build. It sets SPHINXSOURCEDIR to the repository root and SPHINXBUILDDIR to _build, checks that sphinx-build exists before doing anything, and forwards targets through a pattern rule. There is a gettext target that the Makefile comment ties to the godot-docs-l10n repository, which is how translation templates are produced. If you are debugging a build failure, the Makefile is short enough to read in full, and the only non-obvious part is that the source directory is the repository root rather than a docs/ subfolder.

Building the manual locally

The README does not spell out local build steps; it points contributors at the contributing site, which covers building the manual. The repository does give you the pieces: requirements.txt for dependencies and a Makefile for the build. A typical setup follows the pinned requirements, then invokes make with the html target, which the pattern rule forwards to sphinx-build with _build/html as the output directory.

python -m pip install -r requirements.txt

That installs Sphinx 8.1.3, the RTD theme, Pygments and the extensions listed in the file. If pip resolves different versions than the pins, you are no longer reproducing the environment the site is built in.

make html

This runs the pattern rule in the Makefile, which calls sphinx-build with the repository root as the source directory and writes the result under _build/html. The Makefile aborts early with a message if sphinx-build is not on your PATH, so a missing Sphinx shows up as an explicit error rather than a confusing one.

make gettext

This target builds gettext templates with the i18n tag enabled, writing into ../sphinx/templates. The Makefile comment states it is used by the godot-docs-l10n repository, so this is the translation pipeline rather than a normal authoring step. If you only want to preview a change, make html is the target you want.

The offline HTML and ePub downloads, and what they do not cover

This is the part of the repository most useful to people who never intend to contribute. The README offers HTML and ePub archives for three documentation tracks: stable, latest, and 3.6. Both formats are rebuilt every Monday, and both are distributed through nightly.link links in the README rather than through GitHub releases, which is why the repository shows no releases.

For the HTML copy, you extract the ZIP and open the top-level index.html in a browser. For the ePub copy, you extract the archive and open GodotEngine.epub in an e-book reader, which is the practical route on phones and e-readers. The three tracks matter more than they look: stable corresponds to the current stable engine, latest tracks the master branch, and 3.6 exists for projects that have not migrated. Picking the wrong one is the most common way to end up reading about a feature your engine build does not have.

What the offline copies do not give you is a citable, versioned artifact per engine release. They are weekly snapshots, and the README does not describe an archive of past weeks. If you need the documentation as it stood for a specific Godot version, the download links as documented do not provide that.

Licensing splits the repository in two

The licence situation is the one thing to check before you copy text out of this repository. The README states that, with the exception of the classes/ folder, all content is licensed under CC BY 3.0 and is to be attributed to "Juan Linietsky, Ariel Manzur and the Godot community". The files in classes/ are derived from Godot's main source repository and are distributed under the MIT license with the same authors.

That division is not cosmetic. If you are republishing manual prose in a book, a course, or an in-game help screen, the attribution requirement applies to the CC BY 3.0 portion. If you are reusing class reference material, you are dealing with MIT-derived files instead. The repository metadata reports the licence as NOASSERTION, which is a signal that automated tooling cannot reduce this to a single identifier, and the README's two-licence explanation is the reason. This is a description of what the files say, not legal advice; if the distinction matters to your use, read LICENSE.txt and the classes/ provenance yourself.

Where godot-docs is the wrong tool

The clearest failure mode is treating this as the engine repository. It contains no engine source, no build system for the editor, and no GDScript runtime. If your goal is to compile Godot, you are in the wrong place, and no amount of browsing the top-level directories will change that.

The second case is subtler. Because classes/ lives here, contributors sometimes try to fix class reference wording in this repository. The README says those files are derived from Godot's main source repository, which means the canonical text lives elsewhere and the copies here are generated. Editing the generated copy without changing the upstream source is the kind of change that gets reverted on the next sync.

A third limitation is tooling weight. Building the full manual locally means installing a pinned Sphinx stack and its extensions. If all you want is to read the manual, the offline HTML or ePub archives exist precisely so you do not have to do that, and the repository offers no lighter path for a one-off lookup. There is also no documented mechanism here for hosting your own version of the manual; the site build is wired to the project's own deployment through .readthedocs.yml, and the README does not describe a supported fork-and-publish workflow.

How this differs from the engine repository and from other engines' docs

The obvious alternative is godotengine/godot itself. That repository holds the engine source, and it is the upstream for the classes/ folder in this one. The difference in approach is a deliberate separation of concerns: engine code and its build tooling live in one repository, while the manual, tutorials and getting-started material live in another with a completely different toolchain. The practical consequence is that a documentation fix and an engine fix travel through different review processes, and a class reference change has to originate upstream in the engine repository before it appears here.

A second comparison is with engines that keep documentation inside the source tree. That arrangement makes it easier to change code and its documentation in one commit, at the cost of forcing every documentation contributor to work with the engine's build and review conventions. Godot's split means a writer can clone a repository that is only reStructuredText, Sphinx configuration and static assets, install Python dependencies, and build the manual without touching a C++ toolchain. The trade-off is the sync problem in classes/, which is the price of the split.

Maintenance, contribution cost and what to verify

The repository is not archived, and the last push was on 2026-09-22, which is the same day as this assessment. That is a repository receiving changes right now, and the weekly offline builds described in the README are consistent with a project that expects continuous edits.

The contribution path is deliberately routed away from the README. It sends you to contributing.godotengine.org, which hosts the manual contribution guide, the class reference guide, content guidelines, writing guidelines, build instructions and translation instructions. That is a real cost: the README tells you what the repository is and where to go, but the rules for a change, including style requirements, live on a separate site. Budget time to read the writing and content guidelines before your first pull request, because the repository carries a _styleguides/ directory and a pyproject.toml configured for codespell and ruff, which indicates that automated checks run over contributions. The codespell configuration skips classes/, _static/css/, _styleguides/, AUTHORS.md and LICENSE.txt, and carries an explicit ignore list for words like "lod", "uint" and "thirdparty", so a spell-check failure on ordinary technical vocabulary is unlikely but not impossible.

What to verify first depends on your role. If you are contributing prose, confirm whether your file falls under CC BY 3.0 or the MIT-licensed classes/ tree. If you are translating, start from the gettext target and the translation documentation rather than from the English sources. If you are consuming the docs offline, confirm you downloaded the track that matches your engine version, since stable, latest and 3.6 are separate archives.

Editorial conclusion

Adopt godot-docs if you are writing or translating the official Godot manual, or if you need an offline HTML or ePub copy of it. Do not clone it expecting engine source or a GDScript reference you can compile into a game; the classes/ folder is generated from the engine repository and is not the place to file documentation fixes. Before contributing, verify which of the two licences covers the file you are editing, since classes/ is MIT while the rest of the repository is CC BY 3.0, and check the contributing site for the current build instructions rather than assuming the Makefile targets are the whole workflow.

Frequently asked questions

Official sources

1. godotengine/godot-docs on GitHub
2. Issues
3. Project website
4. README