How to password protect a documentation site

The ways to put a password or sign-in in front of a docs site: host-level basic auth, an access proxy, or a docs platform with a gate built in.

By Gusenga Thierry · Updated 2026-10-08

The short answer

Most documentation tools have no password of their own, so you either put one in front of the site at the host (basic auth, Cloudflare Access, a proxy) or publish on a docs platform with an access gate built in. A single shared password is the weakest option: it gets forwarded, and you cannot take it back from one person.

Why is this harder than it should be?

Most documentation is built by a static site generator: Docusaurus, MkDocs, Hugo, Jekyll. They turn markdown into HTML files and stop there. A static file has no idea who is asking for it, so there is nowhere inside the generator to put a password. Whatever does the checking has to sit in front of the files.

That leaves three places it can go: the web server or host, a proxy in front of the host, or a documentation platform that does the serving and the checking itself.

Option 1: a password at the host

If you run your own server, HTTP basic auth is a few lines of nginx or Apache config. The browser shows a username and password box before any page loads.

Some static hosts offer a similar switch on paid plans. Check what yours offers before you build anything.

What you get: the site is no longer public, and search engines stop indexing it.

What you do not get:

Per-person access. Everyone shares one password. When a contractor finishes, you change it and tell everyone else the new one.
Any record. You cannot tell who read the docs, because everyone is the same user.
Anything finer than the whole site. Protecting one section and leaving the rest open usually means a second site.

Option 2: an access proxy

Cloudflare Access, Google's Identity-Aware Proxy and similar tools sit in front of a site and ask the visitor to sign in with an identity provider first. You write a rule such as "anyone with an @yourcompany.com address" and the proxy enforces it.

This is a real step up from a shared password: people sign in as themselves and you can remove one person without touching anyone else. The cost is setup and ownership. You need the domain on that provider, someone has to maintain the rules, and the rules live in a different system from the docs. It works well for a company that already runs one. For a team of five sharing docs with two clients, it is a lot of moving parts.

Option 3: a docs platform with a gate

The third route is to publish on a platform that serves the pages and checks the reader on the same request. Several commercial docs tools offer this, but usually on their upper tiers; the Mintlify, GitBook and ReadMe comparisons go through what each charges for it as of October 2026.

DocuGate is built around this case. It publishes the markdown already in your GitHub repository, and every space has one of three access modes:

Mode	Who can read
Public	Anyone with the link
Repo access	Anyone GitHub lets open the repository
Allowlist	Only the GitHub logins or email addresses you list

There is no password at all. Readers sign in with GitHub, or with Google if they are on an allowlist by email, so a client without a GitHub account can still read. The check happens on the server before any markdown is read; a refused reader gets the space's name and a reason, never the content. The access control docs show the code.

Repo access is the one with no list to maintain. The server reads each page with the reader's own GitHub token, so GitHub decides. Give someone access to the repository and they can read the docs; remove them and they cannot.

Which one should you pick?

You have	Use
A static site, a server you control, and a handful of trusted readers	Basic auth at the host
A company identity provider and someone who runs it	An access proxy
Docs in a GitHub repository and readers you want to name one by one	A docs platform with a gate

A shared password is fine for keeping a staging site out of search results. For anything with commercial or security content in it, such as rate cards, partner integration specs or internal runbooks, you want each reader to sign in as themselves.

How do I gate docs with DocuGate?

Sign up with GitHub.
Open Dashboard → New space and pick the repository.
Choose the branch and the docs folder. Use . for the repository root.
Choose Repo access or Allowlist as the visibility.
For an allowlist, add GitHub logins or email addresses in the space's settings. The list is kept in DocuGate, not in your repository, and is visible only to you.
Send the link. Readers sign in and land on the page they asked for.

Public repositories work on the free Starter plan. Private repositories need Pro, at $5 a month, $50 a year or $2 a week; see pricing.

Try it

Create a space from a repository you already have and set it to Allowlist.

Questions people also ask

Can I add a password to a Docusaurus or MkDocs site?

Not inside the generator. Both build static files with no login step, so the password has to come from whatever serves the files: basic auth on the web server, an access proxy, or your host's protection feature.

Is a shared password good enough for internal docs?

It keeps out search engines and passers-by. It does not tell you who read what, and when one person leaves you have to change the password for everyone. Sign-in per reader solves both.

Does DocuGate use passwords?

No. Readers sign in with GitHub, or with Google if you allowlisted their email address. Each space is Public, Repo access or Allowlist, and you can change it at any time.

Can I protect only part of my documentation?

In DocuGate, yes. Access is set per space, and several spaces can read different folders of the same repository, so docs/public can be public while docs/partners is allowlisted.