Password protection

Password-protect your site so only people with the password can open it. Visitors see a branded login page — no browser popup — before they reach your app.

The gate covers your app's own address only. A PocketBase host (pb-<app>.percher.run) stays public; see PocketBase.

Every app is public by default. Its URL is openly reachable, so protection is opt-in. It takes two steps that work together, then applies on your next deploy.

# 1. Turn on the gate — add this to your [web] block in percher.toml
[web]
password = true

# 2. Set the actual password (stored encrypted; never put it in percher.toml)
bunx percher env set SITE_PASSWORD=your-secret-here

# 3. Deploy — protection is applied during the deploy
bunx percher publish

Both pieces are required — the “password = true” switch and the SITE_PASSWORD secret. Setting one without the other does not protect the site. To confirm it worked, open your app's URL: you should see the login page first. To turn it off, set password = false (or remove the line) and deploy again.

All plans. No extra cost. Visitors who enter the correct password get a 7-day cookie — they won't be asked again until it expires. Rotating SITE_PASSWORD takes effect without a redeploy and invalidates every existing cookie within about 30 seconds.

Explicit form. “password = true” is the legacy alias for visibility = "password". The full field is visibility = "public" | "password" | "private" under [web]. “public” is the default; “password” is the SITE_PASSWORD gate above; “private” — a Percher-login gate where only the owner and the people you invite can open the app, each signed in with their own Percher account, no shared secret. Don't combine visibility = "public" with password = true.

With visibility = "password", set SITE_PASSWORD before you deploy. Only password = true blocks the deploy when the secret is missing; the explicit form does not, and the app then shows a login page nobody can pass.