Password-Protected CDN Domains
Ship a dev build to a Storage bucket, put it on a test domain, and share the URL without sharing it with the whole internet.
Sharing without publishing
Every team hits this at some point: you have a build that needs to be seen — by a client, a designer, a stakeholder — but it is not ready for the world. The usual workarounds are all bad in their own way. Obscure URLs leak. VPNs are friction for outsiders. Authentication baked into the app itself means writing code that will be thrown away.
Password protection on Edge CDN solves this with the oldest, most universally supported mechanism on the web: HTTP Basic Auth. Any CDN domain can require a username and password. Visitors get their browser's native credential prompt before anything is served, and everyone with the credentials gets the full site over HTTPS at full CDN speed. No app changes, no extra infrastructure, no per-seat licences.
How it works
The credential check runs on the edge node itself, ahead of everything else in the request pipeline — before the cache lookup and before any origin fetch. That ordering matters: many CDN-level protections only guard origin fetches, which means content already sitting in cache can slip out unauthenticated. On Edge, protected content is never served without credentials, including cached content.
- Enforced at the edge, ahead of the cache — a request without valid
credentials gets a
401and the browser's login prompt. Nothing is served, cached or otherwise. - Passwords stored as bcrypt hashes — the plaintext is hashed the moment you save it. Edge nodes only ever receive the hash, never the password.
- Verified credentials are cached at the edge — the deliberately slow bcrypt check runs once per credential, not per request, so authenticated traffic runs at full CDN speed.
- Failed attempts pay the full bcrypt cost every time — the hash's ~100ms work factor doubles as built-in brute-force rate limiting.
- SSL issuance and renewal keep working — certificate validation requests are exempt from the check, so protected domains still get automatic HTTPS.
Setting it up
Protection is one click from the Domains tab of any CDN deployment:
- Open your deployment's Domains tab in the control panel
- Click the lock icon on the domain you want to protect
- Enable Require a username and password and set the credentials
- Save — protection is live on the edge within seconds
A protected domain shows a Protected badge in the domain list. To change the password, open the same modal and enter a new one; to change just the username, leave the password blank and the existing one is kept. Turning protection off is the same checkbox in reverse.
The private dev preview recipe
The pattern this feature was built for, end to end:
- Upload the build to an Edge Storage bucket — from the control panel, the CLI, or CI
- Add a domain to a CDN deployment with the bucket as its origin
(a
test.networksubdomain works out of the box, no DNS setup needed) - Enable password protection on the domain
- Share the URL and credentials — recipients open the link, enter the username and password once, and browse the build over HTTPS
For scripted access — CI smoke tests, automated screenshots — pass credentials the standard Basic Auth way:
curl -u preview:your-password https://dev.yoursite.test.network/index.htmlWhen the build goes public, flip protection off and the same domain serves the same content to everyone — nothing to migrate.
When to use something else
Basic Auth is a shared secret — everyone uses the same username and password, and revoking access means changing it for everyone. That is exactly right for dev previews, staging sites, and internal tools with a handful of users. It is not a substitute for real user accounts, per-user permissions, or audit trails in a production application.
If what you need is protection from bots rather than from people, that is a different tool: Edge Shield verifies that visitors are human without asking anyone for a password.