Vercel access & project ownership

How Vercel teams and roles work, how to invite people, where environment variables live, and how to transfer a project you own.

Vercel hosts and deploys front-end applications, most commonly Next.js. Access is organised around a team (sometimes still called a scope) that owns projects, domains, and environment variables.

Quick summary

Invite people from Settings → Members on the team. Use the lowest role that works — Viewer for read-only, Member or Developer for day-to-day work, Owner only where it's genuinely needed. Environment variables sit on the project (or team-wide) under Environment Variables, and each one is applied to the environments you pick: Production, Preview, Development, and any custom environment.

How Vercel organises things

Team — the billing and permission boundary. Everything else belongs to it. A personal account is a Hobby team: effectively a team of one, and without the member roles below.

Project — one application, linked to a Git repository, with its own domains, environment variables, and deployment history.

Deployment — one build of one commit, with its own generated URL. A push to any branch other than the production branch gives you a preview deployment; a push to the production branch deploys to production. (The very first deployment of a new project is always a production one.)

Roles

Roles for team members exist on the Pro and Enterprise plans; a Hobby team has no roles to assign. Some role names differ by plan, and two of them are Enterprise-only:

Role	Can do	Use for
Owner	Everything: team settings, billing, all projects, and changing other people's roles	The business owner; keep this small
Member	Full control over projects and most team settings, but can't invite or manage people	Senior engineering
Developer	Deploy and manage projects and domains, and set preview and development variables — but not production variables, and can't invite people	Day-to-day engineering
Viewer	Read-only on projects and deployments. Called Pro Viewer on Pro and Enterprise Viewer on Enterprise	Stakeholders, auditors
Billing	Billing and payment methods, plus read-only access to every project	Finance
Security	Firewall, rate limiting and deployment protection, plus read-only on projects. No deploy rights by default. Enterprise only	Security review
Contributor	No access until you give it: the only role that can be granted per-project roles (Project Administrator, Project Developer or Project Viewer). Enterprise only	Contractors on one project

Inviting someone

Open the team. Select the correct team from the team switcher at the top-left — it's easy to invite someone to a personal account by mistake. Only Owners can invite.

Open Settings in the sidebar and go to Members.

Invite by email, choose the role, and send. The invitation isn't accepted for them: they have 7 days to accept it before it expires (30 days on teams that enforce SAML).

Confirm they enabled 2FA. Deployment access is production access.

Environment variables

Variables are usually set on a project — open the project and choose Environment Variables in the sidebar — but they can also be set team-wide, where every project in the team can read them. Each variable is applied to the environments you select:

Production — the live site
Preview — every branch and pull request deployment, optionally narrowed to one branch
Development — pulled down for local work with vercel env pull
Custom environments — named environments such as staging, on Pro and Enterprise

A change to a variable only affects future deployments, so redeploy after editing one.

Preview deployments are publicly reachable by default

Vercel generates a URL for each deployment, and that URL is publicly accessible unless you make it private with deployment protection. So if a preview environment points at real data or real payment keys, treat it as production. Give previews their own test credentials, and turn on deployment protection if previews must stay private — its Vercel Authentication method is available on every plan.

Variables prefixed to be public — NEXT_PUBLIC_ in Next.js — are bundled into the browser build and are not secrets. See environment variables & secrets.

Transferring a project

Projects can be moved between teams, which is how ownership handovers work.

Check who needs to be who. You have to be an Owner of the team you're transferring from, and a member of the team you're transferring to. The destination team also needs a valid payment method on file first.

Open the project, then Settings → General, scroll to the bottom to the Transfer Project section, and pick the destination team. You can create the new team here if it doesn't exist yet.

Review the list Vercel shows you of the domains, aliases and environment variables that will move, and rename the project if the destination team already has one with that name.

Afterwards, re-add anything that didn't travel. Marketplace integrations have to be added again, log drains and monitoring data don't move, and any variables you had declared in vercel.json rather than in the dashboard need setting up on the new team.

Check the domains. They transfer automatically, but if the project uses a subdomain such as blog.example.com, only the subdomain is delegated — the root domain stays with the old team, and so does the billing for it if it was bought through Vercel. See DNS access.

Expect a short freeze, not downtime

Vercel transfers projects with no downtime, and the Git link, deployments and domains come with it. What you do lose briefly is control: while the transfer runs you can't create deployments, change project settings or delete the project. It usually takes between 10 seconds and 10 minutes, so don't start one in the middle of a release.

Common questions

Does removing someone from the team revoke their access?

It revokes their dashboard access, but that isn't the whole job. Access tokens live on the person's own Vercel account, not on your team, and the linked Git repository is a separate system with its own permissions. Offboarding means all three: remove the member, delete or rotate any token that was created for your work, and remove their Git access.

Who should own the Vercel account — us or our agency?

You. The team that owns the project owns the domains, the deployment history, and the billing relationship. We're happy to work as members of your team. See transferring ownership to you.

Can we roll back a bad deployment?

Yes. Vercel calls it Instant Rollback: you open the production deployment tile on the project and pick an earlier deployment to restore. On Pro and Enterprise any deployment that was previously live on the production domain is eligible; on a Hobby team you can only go back to the immediately previous one. One catch worth knowing before you rely on it: a rollback restores the old build as it was, so environment variables you have changed since are not applied. This is one of the genuine advantages of the platform, and it's why we avoid deleting old deployments.

What happens if billing lapses?

The team that owns the project is also the team that owns your production domains, so a billing problem lands in the worst possible place. Keep a valid payment method on file and point billing alerts at an address someone actually reads. Separately, Pro teams have Spend Management (Enterprise teams need Vercel's Flexible Commitment plan for it), which can be set to pause the production deployment of every project once a spending limit is reached — genuinely useful as a cost cap, but know it exists before someone switches it on.

Need a hand?

If you're stuck, email support@chykalophia.com and we'll help. Include your website address and a screenshot if you can.