Skip to content
PandaStack Docs

Password protection

Password protection puts a single password in front of your whole site. Visitors see a login page before any of your content loads. It’s the fastest way to share a staging build with a client, keep a work-in-progress site private, or lock down an internal tool.

Available on paid plans, for both static sites and container apps, including custom domains and preview environments.

Enable it

Section titled “Enable it”
  1. Open your project in the dashboard.
  2. Find Password protection.
  3. Enter a password (minimum 8 characters) and select Enable.

The change takes effect on the next request — there’s no redeploy and no waiting.

To change the password later, enter a new one and select Change. To make the site public again, select Turn off.

What visitors see

Section titled “What visitors see”

An unauthenticated visitor gets a clean login page asking for the password. After entering it correctly they’re sent to the page they originally requested, and a session keeps them signed in for 7 days on that browser.

The login page works without JavaScript, so it also renders in minimal or text-based browsers.

Changing the password signs everyone out

Section titled “Changing the password signs everyone out”

Every existing session is invalidated the moment you change the password. This is deliberate: if you’re rotating a password because someone shouldn’t have access anymore, that person is locked out immediately rather than staying signed in until their session happens to expire.

Turning protection off and on again has the same effect.

Scripts, CI, and uptime monitors

Section titled “Scripts, CI, and uptime monitors”

Automated clients can authenticate with HTTP Basic auth instead of the login form. The username is ignored — only the password is checked:

Terminal window
curl -u any:your-password https://your-site.pandastack.app/

This keeps CI jobs, webhooks, and uptime monitors working against a protected site.

Trade-offs to know

Section titled “Trade-offs to know”

Search engines can’t index a protected site. That’s the point — but if you protect a site that was previously public and indexed, expect it to drop out of search results.

Protected sites skip the CDN edge cache. A shared cache could otherwise hand a cached page to someone who never signed in, so every request for a protected site is served fresh. Your site stays fast, but it won’t get the extra edge-cache speedup that public static sites do.

One password for the whole site. There are no per-user accounts and no per-path rules — it’s a single shared password covering every page. If you need real user accounts, build authentication into your app instead.

Failed attempts are throttled

Section titled “Failed attempts are throttled”

Repeated wrong passwords from the same address are rate-limited for a short cooldown, so the password can’t be brute-forced by hammering the login page.

Section titled “Related”