minio/docs: building the MinIO object store documentation yourself

The hosted documentation was taken down, so the repository is now the deliverable

The first two lines of the README set the context. As of October 10, 2025, the MinIO object store documentation was pulled from web hosting, and moving forward, community users can build and host the documentation themselves using the instructions below.

That is an unusual situation for a vendor documentation repository, and it changes what the project is. It is no longer the upstream source of a published manual. It is a build recipe plus a set of sources that somebody else can now run and host.

The second line of the README is equally direct about maintenance. No further development of the documentation is planned at this time, and the project maintainers will make best efforts to review and merge PRs from the community. So the repository is a maintenance-mode project with community contributions accepted, and the last push was on 2026-10-02, with the repository not archived.

For a reader, this reframes the question. The interesting question is not which MinIO version does this document, it is whether you can build it, what has to be fetched to build it, and where the content comes from when the build runs. The rest of the README answers those in order.

The topics list gives one more clue about the shape of the thing. It is `documentation`, `minio`, and `sphinx`, and the primary language is listed as SCSS, which reflects the styling layer rather than the prose.

The build is Sphinx on ReST with a gulp step for assets

MinIO uses Sphinx to generate static HTML pages using ReSTructured Text, and the prerequisites are pinned rather than floating.

The list is exact. Any GNU/Linux operating system, or macOS 12.3 or later. Python 3.10.x with python-pip. python3.10-venv. Sphinx 6.2.1. Node.js 14.5.0 or later. npm 16.19.1 or later. And `git` or a git-compatible client.

The `requirements.txt` pins the Python side down to specific versions, and it is worth reading because it shows what the documentation depends on: docutils 0.19, sphinx 6.2.1, and a set of Sphinx extensions covering copy buttons, design elements, markdown tables, substitutions, sitemaps, toggle buttons, images, autoyaml, reredirects, plus myst-parser for Markdown, linkify, linkify-it-py and pyyaml 6.0.1.

The JavaScript side is gulp. The `package.json` for the documentation is named `minio-documentation` with a main of `index.rst`, and the scripts are `watch` running `gulp watch`, `build` and `gulp` both running `gulp`, and a `test` script that echoes an error and exits, meaning there is no JavaScript test suite. The dev dependencies are the gulp toolchain, with gulp-sass and sass 1.49.0 for styling, autoprefixer, clean-css, terser, connect for the dev server, and rename and load-plugins as glue. The `browserslist` field is `last 2 versions`.

So the asset pipeline compiles SCSS to CSS and minifies it, and the prose pipeline is Sphinx. The Makefile sits on top of both, with `SPHINXOPTS` defaulting to `-n -j auto -w "build.log"` so nitpicky warnings are enabled, parallel jobs are automatic, and a log file is written, with `SOURCEDIR` as `source` and `BUILDDIR` as `build`.

Five commands take you from clone to a local documentation server

The build instructions are numbered and short enough to follow end to end.

First, clone the repository locally:

git clone https://github.com/minio/docs && cd docs/

Second, create a Python virtual environment:

python3 -m venv venv && source venv/bin/activate

Third, install the Python and Node dependencies:

pip install -r requirements.txt && npm install && npm run build

Fourth, build the documentation:

make SYNC_SDK=true mindocs

`SYNC_SDK=true` pulls down SDK-related dependencies from MinIO's community S3 libraries, and the README says you can omit `SYNC_SDK` on subsequent builds, which is the difference between a first build and an incremental one.

Fifth, view the result:

python -m http.server --directory build/YOUR_BRANCH/<PLATFORM>/html

That last path is the detail that explains the Makefile. The output is keyed by branch and then by platform, so `build/YOUR_BRANCH/<PLATFORM>/html` is not a placeholder to fill in casually, it is the shape of the directory tree the Makefile creates. The Makefile confirms it, since it derives `GITDIR` from `git rev-parse --abbrev-ref HEAD` and the clean targets remove `$(BUILDDIR)/$(GITDIR)`.

The README also notes that the instructions do work on macOS for testing purposes, while GNU/Linux is recommended for production builds.

The operator CRD sync is a separate, heavier path

Syncing the Operator CRD documentation is documented as a distinct operation with extra prerequisites, and it is the part of the build that pulls in the most external dependencies.

Beyond everything else, you need pandoc at latest stable and asciidoc at latest stable, and the command is:

make sync-operator-crd

The script does three things. It downloads and converts the `tenant-crd.adoc` from the MinIO Operator GitHub repository, downloads the Operator Helm `values.yaml` from the same place, and downloads the Tenant Helm `values.yaml` from the Operator GitHub repository.

The conversion path for `tenant-crd.adoc` is asciidoc to XML and then XML to markdown, and finally some `sed` find and replace to tidy the file for Sphinx ingest. That last step is the fragile one. Asciidoc to XML to Markdown loses structure, and a regular expression pass over the result to make it acceptable to Sphinx is the kind of thing that breaks when the upstream document changes shape.

The README explains when to run it, and the reasoning is worth reading. You run it when there is a new Operator release being documented, assuming there are changes to the CRD as part of that release, and the goal is to make it somewhat easier to periodically sync these docs instead of pulling them down on every single build, when you do not expect or need doc changes in the latest stable.

That framing tells you the build normally does not fetch operator content at all, and this target is for the release cycle rather than for every build. The repository top level confirms the structure, with `sync-minio-operator-crd.sh`, `sync-minio-server-docs.sh` and `sync-minio-version.sh` as separate scripts alongside the `Makefile`.

The licence changed from AGPL3.0 to CC-BY-4.0

The licensing history is stated in the README and it is a genuine change of terms rather than a formality.

The project is licensed under a Creative Commons Attribution 4.0 International License, and the README points at CONTRIBUTING.md for more information on contributing to the MinIO Documentation project.

Then the note: this work was previously licensed under AGPL3.0, and you can find all AGPL3.0 licensed code at a specific commit, 73772c7f8485809446cc890188a89ece1afb93f6.

CC-BY-4.0 is a content licence rather than a software licence, which fits a documentation project that is mostly prose, and it is a much lighter set of obligations than AGPL for anyone reusing the text. It is worth checking which terms apply to the exact commit you are looking at, because the boundary is a specific commit rather than a date, and this is not legal advice.

There is one inconsistency in the repository worth flagging. The `package.json` for the documentation declares `license: Apache-2.0` in its metadata, while the LICENSE file and the README both say CC-BY-4.0. The two files disagree, and the LICENSE file plus the README is the pair that matches the stated history, so treat the manifest field as a leftover rather than a second grant.

The repository top level shows the rest of the structure, with a `source/` directory for the ReST sources, a `sphinxext/` directory for custom Sphinx extensions, `build-docs.sh` and `build-docs-ci.sh` for the build wrappers, a `gulpfile.js` for the asset pipeline, `staging.env` and `stage.sh` for the staging flow, and `new-platform.md` for adding a platform.

Editorial conclusion

Adopt minio/docs if you need to host and rebuild the MinIO object store documentation for your own product or mirror, and you are prepared to own the hosting and the syncing scripts. Do not expect an actively maintained upstream manual set, because the README says no further development of the documentation is planned and that the maintainers will make best efforts to review and merge community pull requests. Verify first that the version of the docs you clone matches the MinIO release you are documenting, since the build path is per branch and per platform.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-4.0
3. minio/docs on GitHub
4. README