Netlify Teams lets you centralize access control for multiple sites, but it doesn’t actually manage permissions per site directly. Instead, it grants roles to users at the team level, and those roles determine what they can do across all sites within that team.
Let’s see this in action. Imagine you have a team called "Acme Corp" with two sites: acme-marketing.netlify.app and acme-internal.netlify.app. You want to give your designer, Sarah, read-only access to the marketing site but full admin access to the internal site.
Here’s how you’d actually do it, and why it’s not as granular as you might expect:
-
Add Sarah to the "Acme Corp" Team:
- Go to your Netlify dashboard.
- Navigate to the "Team settings" for "Acme Corp."
- Click "Add member" and invite Sarah with her email.
-
Assign Sarah a Role:
-
When you invite Sarah, you’ll assign her a role. The available roles are:
- Owner: Full control over the team, billing, and all sites.
- Admin: Can manage sites, deploy, and invite members, but cannot manage billing or change team ownership.
- Member: Can view sites, deploy, and manage individual site settings, but cannot invite members or change team-level settings.
- Billing: Can manage billing settings but cannot access site content or deployments.
-
The Catch: There’s no "Viewer" role that’s limited to specific sites, nor a role that grants "Admin" to one site and "Member" to another within the same team. If you assign Sarah "Admin" on the team level, she has admin rights across both
acme-marketing.netlify.appandacme-internal.netlify.app. If you assign her "Member," she has member rights across both.
-
-
Simulating Granular Access (The Workaround):
Since Netlify Teams doesn’t offer per-site role assignments directly, you have to get creative. The most common approach is to use separate teams for distinct access needs.
-
Scenario: Sarah needs full admin for
acme-internal.netlify.appbut only read-only foracme-marketing.netlify.app. -
Solution:
- Team 1: "Acme Corp - Marketing"
- Invite Sarah as a "Member." (This allows her to view and deploy, but not change core settings or invite others.)
- Invite your marketing team members as "Members."
- Invite yourself or a lead as "Owner" or "Admin."
- Team 2: "Acme Corp - Internal"
- Invite Sarah as an "Admin." (This gives her full control over this specific site.)
- Invite only the necessary internal team members as "Admin" or "Member."
- Team 1: "Acme Corp - Marketing"
-
Why this works: By splitting your sites into different teams, you can then assign roles to users per team. Sarah is a "Member" of the "Acme Corp - Marketing" team (giving her limited access to
acme-marketing.netlify.app) and an "Admin" of the "Acme Corp - Internal" team (giving her full access toacme-internal.netlify.app). She’ll have to switch between teams in her Netlify dashboard to access different sites. -
The "Read-Only" Problem: Netlify doesn’t have a true "read-only" role. The "Member" role is the closest you get, allowing viewing and deploying, but not altering critical settings like build commands or environment variables. For true read-only, you’d typically rely on external tools or simply instruct users to avoid making changes.
-
Another Workaround (Less Ideal): If you have a very small number of sites and a very specific need for granular control, you could create separate teams for each site. This quickly becomes unmanageable for larger organizations.
-
Alternative for Sensitive Data: If a site contains highly sensitive data and you need to restrict access even further, consider not including that site in a shared team at all. Instead, create a dedicated team with only the essential personnel.
-
This layered approach is how Netlify manages access control for multiple sites: by defining roles at the team level and then using multiple teams to segment access when per-site granularity is required.
The next hurdle you’ll encounter is understanding how Netlify’s role assignments interact with its feature flags and site-specific settings.