Vercel Logo

Deployment Protection

Sneaker forums have a folder for leaked photos. There's usually a sub-folder for leaked photos that came from someone's preview URL: a staging build for an upcoming drop, indexed by Google, shared in a Discord, traced back to a domain that ends in .vercel.app. The brand finds out the same time the resellers do.

Saturday's previews are public right now. Anyone with the URL can see what's coming. Push a branch called feature/foundry-stealth-colorway and the preview deployment is one Google query away from being on Instagram. The branch name is right there in the URL.

Deployment Protection puts a login screen in front of any preview that isn't production. Only people on your team (or people you've granted access to the project) get through. That's what we want for Saturday.

What is Deployment Protection?

A project setting that puts an access check in front of your deployments before they render. Vercel Authentication, the flavor available on every plan, requires the visitor to be a logged-in member of your team.

Outcome

Saturday's preview deployments require a Vercel-authenticated user to load. Production stays public.

Hands-on exercise 2.2

Lock down previews without locking down the public site.

Requirements:

  1. Open Saturday > Settings > Deployment Protection
  2. Under Vercel Authentication, set the scope to Standard Protection, which protects everything except your production domains
  3. Leave production unprotected. Saturday is a public site; production needs to be reachable by anyone.
  4. Push a new feature branch with any tiny change (a comment in app/page.tsx is enough) so a preview deployment builds
  5. Open the preview URL in a private browser window and confirm you get the Vercel login screen instead of the page

Implementation hints:

  • Vercel Authentication is the recommended method and works on every plan including Hobby. Password Protection (Enterprise, or a paid add-on on Pro) and Trusted IPs (Enterprise only) are stronger. We cover those in Lesson 6.3.
  • Standard Protection is what you want. It gates previews and the auto-generated production URLs (the long saturday-abc123.vercel.app ones) while your actual production domain stays public. The All Deployments option would gate the production domain too, which would break Saturday's whole reason for existing.
  • A private window matters for the test. Your regular browser is already signed into Vercel, so it'll pass the auth check silently and you won't see the protection in action.
  • If a teammate needs to view a preview without being on the Vercel team, you can grant per-deployment access from the deployment page. Don't do this casually, that link, once shared, has the same leak problem we started with.

Try It

Push the feature branch:

git checkout -b feature/test-deployment-protection
echo "// testing deployment protection" >> app/page.tsx
git commit -am "test: deployment protection"
git push -u origin feature/test-deployment-protection

Wait for Vercel to build the preview. The URL will look like https://saturday-git-feature-test-deployment-protection-yourname.vercel.app.

Open that URL in a private window. Instead of Saturday's homepage, you should land on Vercel's authentication screen asking you to sign in. Sign in with the account that's on the team and you should land on the homepage. That's the round trip working.

Visit your production domain (the short saturday-yourname.vercel.app one, or your custom domain) in the same private window. It should load Saturday normally, no auth screen. That's the "previews locked, production open" configuration doing its job.

Done-When

  • Settings > Deployment Protection shows Vercel Authentication with Standard Protection
  • Production is not gated (anonymous users can load Saturday at its production URL)
  • An incognito visit to a preview URL prompts for Vercel login
  • Signed-in team members reach previews normally

Troubleshooting

My production URL is asking for login too.

Check which URL you're on. Under Standard Protection, the long auto-generated production URLs (saturday-abc123.vercel.app) are gated on purpose; only your production domain is public. If the production domain itself is asking for login, the scope is set to All Deployments. Change it to Standard Protection and the domain loads normally on the next request.

A teammate can't view the preview even though they're on the team.

They might not have project access. Team membership and project access are not always the same: a Member at the team level might have View-Only or No Access on individual projects depending on how RBAC is set up. We get into that in Lesson 5.2. For now, check Saturday > Settings > Members and confirm they're listed for the project.

The preview still loads without prompting for auth.

You're probably still signed in. Protection is checked at request time and covers existing deployments the moment you enable it, no rebuild needed, so the usual culprit is a browser session that's already authenticated with Vercel. Use a genuinely private window, or a different browser. If it still loads, confirm the setting actually saved and that you're looking at the right project.

Solution

No code in the repo to commit. The state is the configuration:

Settings > Deployment Protection
  Method:           Vercel Authentication
  Scope:            Standard Protection
  Production domain: Public

Clean up the test branch when you're done so it doesn't clutter your branch list:

git checkout main
git branch -D feature/test-deployment-protection
git push origin --delete feature/test-deployment-protection

We've locked the front door of preview deployments. Next we'll add a deadbolt to a specific API route that bots like to hammer.

Was this helpful?

supported.