Preview Lockdown

Lesson 2.2 gated Saturday's previews behind Vercel Authentication. For most projects that's enough. For the one preview where a leak would cost you a deal (a private collaboration with another brand, a confidential collab drop in staging, a pricing page going to legal review), you want more layers.

Vercel Authentication says "you must be signed in to the team." Password Protection says "and you must know this code." Trusted IPs says "and you must be on this network." They stack. Hit a protected preview without all three credentials and you don't get in.

For Saturday, you probably don't need all three on every preview. The point of this lesson is to know how, so the next time you have a high-stakes collab brewing (a Foundry x [famous designer] colorway, an embargo'd review embed), you can lock it down in two minutes.

Outcome

You've layered Vercel Authentication, Password Protection, and Trusted IPs on Saturday's preview deployments. You can verify each layer blocks unauthenticated access.

Hands-on exercise 6.3

The three layers configured one at a time.

Requirements:

1. Confirm Vercel Authentication is enabled (from Lesson 2.2). Settings > Deployment Protection should still show Vercel Authentication with Standard Protection.
2. Enable Password Protection on the same Deployment Protection page
   • Set a strong password (16+ characters, generated randomly)
   • Choose "Preview Deployments Only" or equivalent
   • Save the password somewhere your team can access it (1Password shared vault, not Slack)
3. Enable Trusted IPs on the same page
   • Add the addresses that should be allowed: your office IP, your VPN's egress IPs, your contractors' static IPs
   • IPv4 addresses and IPv4 CIDR ranges only; IPv6 isn't supported here
4. Push a feature branch to trigger a new preview deployment
5. Open the preview URL and watch the layers stack

Implementation hints:

• Trusted IPs is the most fragile of the three. If your office moves, if you change VPN providers, if a contractor leaves, you have to update the list. Have a process.
• A team member working from a coffee shop won't have your office IP. If they need preview access while remote, the realistic options are: (a) connect to your VPN, (b) give them a one-off magic link from Vercel's per-deployment access UI, or (c) accept the IP restriction will sometimes inconvenience legitimate users.
• Password Protection has rotation built in. You can change the password at any time and existing sessions invalidate. A monthly rotation is sane for a small team.
• The layers aren't fully independent: on previews, Trusted IPs can only be enabled while Vercel Authentication is also on. Whatever order the prompts arrive in, all the enabled layers must pass, and a failure at any one stops the request.

Try It

Open a preview URL from outside your trusted IP range (use a phone on cellular, or a coffee-shop wifi):

404
No Deployment Found

That 404 is deliberate. An untrusted visitor doesn't get told "you're blocked"; they get told nothing exists. A leak hunter can't even confirm the preview is there.

Now open the same URL from a trusted IP. You should see the Vercel Authentication prompt:

Vercel Authentication Required
[ Sign in with Vercel ]

Sign in. You should see the Password Protection prompt:

This deployment is password-protected
Enter the access password:
[                                    ]

Enter the password. You should land on the preview.

The layers stack, with one dependency to remember: Trusted IPs on previews rides on Vercel Authentication, so you can't keep the IP wall and drop the sign-in. Turn off Password Protection and the other two still gate. Turn everything off and the preview is fully public.

Done-When

• Vercel Authentication is enabled for previews
• Password Protection is enabled with a strong password
• Trusted IPs has at least one CIDR range allowed (your office or VPN)
• Accessing a preview from an untrusted IP returns a 404 (No Deployment Found)
• Accessing from a trusted IP prompts for sign-in
• Signing in prompts for the deployment password

Troubleshooting

Trusted IP check fails for my office.

Confirm your office's actual egress IP, sometimes the public IP is different from the IP you think it is. Visit ifconfig.me or ip.me from a machine at the office to see what the outside world sees. Add that to the trusted list. ISPs occasionally rotate residential and small-business IPs; if you're using a non-static range, expect periodic re-config.

A teammate is in the office but still getting blocked.

Their machine might be tunneling through a VPN to elsewhere, or your wifi might have a separate egress for guest networks. Check what their actual egress IP is from their machine right now.

Password Protection isn't prompting.

The password is saved on first entry in the browser's session. Try a private window to force a fresh prompt. Also confirm the password is enabled at the level you expect (preview vs. all deployments).

The whole thing feels excessive for my use case.

It probably is, for most previews. That's fine. Set up the three layers, then turn off the ones you don't routinely need. Keep the on-call switch ready for the previews where leak risk is high.

Solution

The configuration state:

Settings > Deployment Protection
  Vercel Authentication:    Enabled (Standard Protection)
  Password Protection:       Enabled (Preview Deployments)
                             Password: [stored in shared vault]
  Trusted IPs:               Enabled
                             203.0.113.0/24   (office)
                             198.51.100.10/32 (VPN egress)
                             192.0.2.5/32     (contractor static)

The mental model worth keeping: deployment protection is the gate, and there are multiple kinds of credential you can require at the gate. For Saturday's everyday previews, Vercel Auth alone is plenty. For the launch-day preview where the collab is embargoed, flip all three on for the duration of the embargo, flip the extras off after launch.

Up next: we leave the access controls behind and look at how Vercel functions talk to the rest of your infrastructure.