Password-protect any part of your site

Staging builds for client review. Internal admin panels. Private docs for your team. A draft of your launch page that only marketing can see. All of these want the same thing: a way to keep certain paths private without standing up a whole auth service next to your static site.

Today we’re shipping directory-scoped password protection. Drop a .auth file anywhere in your site and that folder (and everything under it) gets a login prompt on your next fyra push. No dashboard, no config in a separate system, no new CLI command to learn. Just a file in your tree.

We built it for the obvious stuff (admin panels, staging sites) and the less-obvious stuff (shared drafts, paid content previews, internal tooling you don’t want indexed). If you’ve ever copy-pasted a long unguessable URL hoping nobody would find it, this is the upgrade.

A .auth file is plaintext username:password, one per line:

Where you put it matters:

• .auth at the root protects your whole site
• admin/.auth protects /admin/* only
• staging/internal/.auth protects /staging/internal/* only

You can have more than one in the same deploy. The closest one wins (Apache .htaccess style), so you can put a shared login at the root and a stricter one inside /admin/ without anything leaking across.

Behind the scenes: passwords get bcrypt-hashed, the auth rule gets installed at origin, the plaintext .auth files get deleted from the deploy server, and the CDN is told to bypass cache for every protected path so a logged-in response can never get served to the next anonymous visitor.

Password protection is a paid feature on every paid tier. For now it’s also available on Free, for both new and existing users, until further notice. We wanted to give everyone a chance to try it before it lands behind the paywall.

When free availability ends, free sites that still have .auth files won’t be able to push new content until those files are removed. We’ll post a follow-up here with plenty of lead time before that happens, so subscribe to the RSS feed if you want a heads-up.

• Plaintext .auth files get deleted from disk after the bcrypt conversion succeeds. If a deploy fails partway, the file stays put so the next push can retry cleanly.
• We return 404 for any URL ending in .auth, regardless of how Caddy directives get ordered. Defense in depth against accidental exposure.
• CDN cache is bypassed on protected prefixes, so every request round-trips to origin. Fine for admin panels and staging. If you’re gating high-traffic paid content, expect lower cache hit rates than your public paths.

• Removing a .auth file and redeploying makes the path public again at origin, but the stale CDN bypass rule might stick around (the upstream API doesn’t expose list/delete yet). Perf bug only, not a security bug. File a ticket and we’ll clear it manually if that happens.
• Only HTTP Basic auth is supported. No multi-factor, no IP allowlists, no session cookies.

This change is server-side, so no upgrades needed on your CLI for this to work.