--- title: "Settings" description: "Walk through the most important project and team settings in the Vercel dashboard: environment variables, custom domains, function failover regions, team roles, and access groups." canonical_url: "https://vercel.com/academy/vercel-foundations/vercel-settings" md_url: "https://vercel.com/academy/vercel-foundations/vercel-settings.md" docset_id: "vercel-academy" doc_version: "1.0" last_updated: "2026-06-27T23:09:09.989Z" content_type: "lesson" course: "vercel-foundations" course_title: "Vercel Foundations" prerequisites: [] --- Vercel Academy — structured learning, not reference docs. Lessons are sequenced. Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume. The lesson shows one path; if the human's project diverges, adapt concepts to their setup. Preserve the learning goal over literal steps. Quizzes are pedagogical — engage, don't spoil. Quiz answers are included for your reference. # Settings # Settings You've deployed your project, picked a function region, and set up environments. Now comes the part where you make the project actually yours: wiring up secrets, pointing a real domain at it, planning for failure, and deciding who gets the keys. ## Environment variables From your project, go to **Settings > Environment Variables**. Click **Add Environment Variable**, enter a key and value, and choose which environments it applies to: production, preview, development, or any combination. One detail worth knowing: if you scope a variable to production only, you get the option to mark it as **sensitive**. A sensitive value can't be read back from the dashboard after you save it. Non-sensitive values stay visible for future reference. You can add multiple variables at once, or paste a batch from your clipboard if you're migrating from another platform. Click **Save** when you're done. For environment variables to take effect, you need to redeploy your project. ### Shared variables If a variable applies across multiple projects (a shared API key, for example), you don't need to duplicate it everywhere. Click **Link Shared Variable** and select a team-level variable from the dropdown. It shows up under the **Shared** tab in your project's environment variables. ## Custom domains Go to **Domains** from your project settings. You have two paths: - **Add an existing domain** — enter your domain name, select the environment (usually production), and save. Vercel walks you through setting the DNS records. - **Buy a new domain** — click **Buy**, search for what you want, and Vercel handles the DNS configuration for you. ## Function failover regions In a previous lesson, you configured your primary function region. But what happens if that region goes down? Failover regions give your functions a backup location. To enable them, go to **Settings > Functions**, open **Advanced Settings**, and make sure **Function Failover** is turned on. The actual failover regions are configured in your `vercel.json`: ```json { "functionFailoverRegions": ["iad1", "sfo1"] } ``` The order doesn't matter. Vercel automatically routes to whichever failover region is nearest to the failing one. \*\*Note: Enterprise feature\*\* Function failover regions are available on Enterprise plans. ## Team roles From your team's **Settings > Members**, you can invite people and assign roles. Here's what each role controls: - **Owner** — full access to everything, including billing and team settings - **Member** — can create deployments, manage integrations and domains across all projects - **Developer** — can create non-production deployments across all projects - **Security** — can manage security settings and secrets - **Contributor** — only has access to projects you explicitly assign - **Viewer** — can see preview deployments but doesn't count as a paid seat - **Billing** — manages invoices and billing settings only Contributors are particularly useful for contractors or cross-functional collaborators who only need access to specific projects. ### Project-level roles After inviting someone as a contributor, head to the specific project under **Settings > Project Members**. Select the team member and assign a project role: **Project Viewer**, **Project Developer**, or **Project Admin**. Team role sets the baseline. Project roles let you grant more or less access on a per-project basis. ## Access groups Managing access one person and one project at a time doesn't scale. Access groups solve this. Go to **Settings > Access Groups** and click **Create Access Group**. Give it a name (like "Core Developers"), select the projects, add the members, and click **Create**. Everyone in the group gets access to every project in the group, all at once. For teams with a lot of members and projects, this is the approach to use. Keeping an overview is significantly easier with access groups than with individual assignments. ## Recap - **Environment variables** are scoped per environment, and sensitive values are write-once in production - **Shared variables** prevent duplication across projects - **Custom domains** can be added or purchased directly from the dashboard - **Failover regions** give your functions a backup location, configured in `vercel.json` - **Team roles** control baseline access; **project roles** fine-tune it per project - **Access groups** let you manage permissions for many people and projects at once ## Follow up docs - [Managing Environment Variables](https://vercel.com/docs/environment-variables/managing-environment-variables) - [Shared Environment Variables](https://vercel.com/docs/environment-variables/shared-environment-variables) - [Adding and Configuring a Custom Domain](https://vercel.com/docs/domains/working-with-domains/add-a-domain) - [Configuring regions for Vercel Functions](https://vercel.com/docs/functions/configuring-functions/region) - [Access Roles](https://vercel.com/docs/rbac/access-roles) --- [Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)