Choose a Host for a Password-Protected Website

The host must check access

For a password-protected website, choose a host that checks access before it serves the page and its files. This rule excludes the most common shortcut: a password box in the JavaScript of the page. With that shortcut, the browser downloads the HTML, the script and often the protected content before the check runs. Anyone can then read the content in the page source or open a file by its direct URL.

Real protection works the other way round. The visitor asks for a page, and the host checks the password or identity. Only then does the host send anything. This guide compares the hosts that can do that for a static site, which is a site made only of files. It shows the setup on each host. It also lists the tests to run before you send the link.

Compare the options

Host	Method	Who gets in	Plan requirement
Cloudflare Pages with Cloudflare Access	Email one-time PIN or your identity provider	People on your email or domain list	Access is part of Cloudflare Zero Trust
Netlify	One shared site password, or team login	Anyone with the password	Pro or Enterprise, not credit-based Free or Personal
Netlify _headers file	Basic authentication on chosen paths	Anyone with a listed username and password	Pro or Enterprise
Vercel	Vercel Authentication	Vercel users that you give access to, or anyone with a Shareable Link	All plans
Vercel	Password Protection	Anyone with the password	Pro (paid option) or Enterprise, not Hobby
GitHub Pages	Private site visibility	People with read access to the repository	GitHub Enterprise Cloud only

Plan rules change. Before you decide, read the current pages: Netlify password protection, Vercel Deployment Protection, Cloudflare one-time PIN and GitHub Pages visibility.

Shared password or individual sign-in?

A shared password is simple for a small group. Everyone gets the same password, and anyone who receives it can pass it on. When one reviewer leaves the project, you have to change the password for everyone.

Individual sign-in asks each visitor to prove who they are, usually with a code that the host sends to their email address. You list the people who can enter, by address or by company domain. You can remove one person and keep access for the others. This method suits client portals, investor updates, internal reports and gated demos when you need to know who can get in.

An email field next to a shared password is not the same thing. Unless the host sends a code to that address, the email field only records what people typed.

As a rule, use a shared password for a short review with two or three people that you trust. Use individual sign-in for anything that stays online longer or reaches more people.

Option 1: Cloudflare Pages with Cloudflare Access

Cloudflare Pages hosts the static files, and Cloudflare Access puts a sign-in step in front of them. With the one-time PIN method, a visitor enters an email address, receives a code and pastes it in. The PIN expires 10 minutes after the visitor asks for it. Access sends codes only to addresses that your policy allows.

1. Deploy the site to Pages from Git, or upload the folder.
2. In the Pages project, open Settings. Select Enable access policy. This setting alone protects only preview deployments.
3. To protect the main <project>.pages.dev address, follow Cloudflare’s known-issues steps. Select Manage on the policy. Open the application under Access > Applications > Configure. Under Public hostname, delete the * from Subdomain and save. To keep the previews protected, select Enable access policy again under Settings > General.
4. Edit the Include rule of the policy. Use Emails for named people. Use Emails ending in for a whole domain (Access policies).
5. Add the login method under Zero Trust > Integrations > Identity providers > Add new identity provider > One-time PIN.
6. For a custom domain, create a separate Self-hosted and private application under Zero Trust > Access controls > Applications. Use your domain as the public hostname. Without this application, the sign-in page shows on the custom domain but does not work.

For all the details, read Cloudflare Pages password protection with Access.

Option 2: Netlify password protection

Netlify’s basic password protection puts one site-wide password in front of the site.

1. Open the project in Netlify. Go to Project configuration > General > Visitor access.
2. On credit-based Pro plans, open Project visibility. Select Edit visibility and choose Password. On Enterprise, Open Source and older plans that are not credit-based, the name of the setting is Password Protection.
3. Set the password. Then choose the scope. To protect the live site and not only the previews, pick Production and previews (or Protect all deploys).
4. Save the settings. Then test the site in a private window.

If you need several logins on part of a site, use basic authentication. Netlify supports it through a _headers file on Pro and Enterprise plans. For example:

/protected/*  Basic-Auth: reviewer:choose-a-long-password

Netlify’s own basic authentication page warns that this method has no logout. For sensitive material, it recommends JWT-based visitor access. Never commit the _headers file to a public repository. The file holds the passwords in plain text. For the steps with screenshots, read How to password protect a Netlify site.

Option 3: Vercel Deployment Protection

Vercel has two methods for this. Both are under Settings > Deployment Protection in the project.

Vercel Authentication is available on all plans. Visitors log in with a Vercel account, and you approve their access requests. You can also create a Shareable Link for a deployment. Anyone with that link can get in. On Hobby, you can have one external user and one Shareable Link per account.

Password Protection asks for one password. It is available on Pro as a paid option and on Enterprise, but not on Hobby. Turn it on and choose the environment. Enter the password and select Save. Visitors enter the password once for each deployment URL. If you change the password, everyone must enter the new one.

Look carefully at the scope. Standard Protection protects every deployment except your production domains. To protect the live site itself, choose All Deployments. For details, read How to password protect a Vercel deployment.

What GitHub Pages can and cannot do

GitHub Pages has no password option. On GitHub Free, the repository must be public. Pages sites are public on the internet even when the repository is private. Private visibility exists only for organizations on GitHub Enterprise Cloud. With it, only people with read access to the repository can view the site.

If your site is on GitHub Pages and needs a password, move the files to one of the hosts above. A static folder runs anywhere.

Test the gate before you send the link

The gate is the password or sign-in step in front of the site. Sign out of the host. Then do these tests in a private browser window:

1. Open the homepage. The sign-in or password page must appear before any content.
2. Open a direct link to a file, such as /docs/report.pdf or /assets/chart.png. It must ask for access too.
3. Open every address of the site: the custom domain, the default address of the host (.pages.dev, .netlify.app or .vercel.app) and all preview links. Each address needs its own protection.
4. Sign in as an allowed visitor. Make sure that the content loads.
5. For email sign-in, try an address that is not on the list. It must not receive a code.

Also make sure that the address itself does not show private details. On Pages, Netlify and Vercel, the project name becomes part of the default address. If the project name is confidential or contains the name of a client, change it before you share the link. Later, you cannot always rename the project, and a new name changes the default address.

Update without changing the link

Deploy changes to the same project. The address and the protection settings stay in place. Reviewers keep the link and the password or sign-in that they already have. After each update, open the shared URL in a private window again. Make sure that both the content and the gate work.

Before you buy a plan, test the protection method on a small sample site. Test the custom domain, the default address, preview links and direct file downloads. Keep a copy of the source of the site on your computer. Then the hosting choice never locks you into one provider.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.