Protect deployments and access

Two things can go wrong with access on Vercel. A Preview URL leaks a feature or test data you weren’t ready to show. Or a token or team role is broad enough that one mistake, or one stolen credential, changes every project in the team.

The fix for both is the same old principle: give each person and each tool the smallest access that still does the job.

People and roles

Turn on two-factor authentication for every team member. Then look at roles. Not everyone who deploys needs to be an Owner. Most people need Member, and someone who only reviews previews needs Viewer. Vercel’s team settings show who has what. Read the list once a quarter and remove whoever left.

Tokens and integrations

Automation needs tokens, and tokens are where least privilege gets forgotten. When you create one in Account Settings and then Tokens, scope it to one team, give it an expiry, and name it after what uses it: github-actions-field-notes, not token2. A token that can deploy every project in the team is one leaked CI log away from a bad day.

Do the same review for the connected Git provider and any marketplace integrations. Each one has access you granted once and probably never looked at again.

Protect the previews

Deployment Protection, in the project settings, puts an authentication wall in front of Preview deployments and the unique deployment URLs, while the production domain stays public. Vercel Authentication requires a Vercel login and is on every plan. Password Protection is a paid add-on on Pro and included on Enterprise, and Trusted IPs is Enterprise only.

Turn it on for Field Notes, then prove it works from a private browser window with no session:

curl -sI https://field-notes-git-footer-year-flavio.vercel.app | head -1
# HTTP/2 401

And confirm the production domain still answers 200. Test both hostnames, because a protected branch URL with an unprotected unique URL protects nothing.

One warning. Protection guards the door. It doesn’t clean the room. If a Preview is wired to production data, an authenticated reviewer still sees real customer records. Keep Preview credentials and datasets separate even when the URL requires a login.

Draw the path

Sketch every step a change takes to reach users: the Git provider, the Vercel team, the project, the automation token, the preview viewers, whoever administers DNS, and the external database. At each step, ask who has access and whether they need it. Remove access at the narrowest point. Then check the other direction: if you removed yourself, would at least one accountable person still be able to recover the project?

Try this on your own project: review members, tokens, Git access, integrations, and preview visibility. Remove one permission nobody needs, or write one line for each remaining one explaining why it exists.