Adding someone to a Netlify team means assigning them a role, and on paid plans most roles consume a billable seat. Knowing which roles cost money and which do not is the difference between a predictable bill and a surprising one.
The mechanics take about a minute. The part worth thinking about is which role someone actually needs, because the default instinct is to give more access than the job requires and then pay for it every month.
Table of contents
- Adding someone
- The roles
- Seats, and the alternative
- Access that is not a team seat
- The general principle
- How this fits the rest of the stack
- FAQ
Adding someone
- Open the team and go to Members in the left navigation.
- Select the option to add or invite members.
- Enter the email address.
- Choose a role.
- Send the invitation.
The invitation goes to that address and they accept by signing in or creating an account. Until they accept, the invitation is pending and can be revoked.
To change a role afterwards, find the person in the members list, open the options menu, and edit the member. Role changes take effect immediately, including downgrades - useful when someone’s involvement in a project ends but they remain at the company.
One detail that catches people: the email address on the invitation must match the address on their account. An invitation to a work address that they accept while signed in with a personal one will not connect, and the pending invitation sits there looking like a bug.
The roles
Roles differ by plan tier, so the set available to you depends on what you are paying for. The broad shape is consistent.
- Owner - full control including billing, team settings, and member management. Keep this to the smallest number of people that is still more than one.
- Collaborator or Developer - can work on sites, trigger deploys, and change site settings, without team-level administrative access. This is the role most engineers should have.
- Billing - access to billing and invoices without site access. Useful for a finance contact who has no reason to touch deploys.
- Reviewer or Content roles - on higher tiers, limited roles aimed at people who review deploy previews or edit content without needing full site access.
Two habits that matter more than the specific names. Never have exactly one Owner - if that person is unavailable, or leaves, recovering ownership of a team is an unpleasant support conversation. And review the member list periodically, because teams accumulate people who left the project a year ago and are still consuming a seat.
A useful default: give the least access that lets someone do their job today, and upgrade when they hit a wall. That is a thirty-second change, and it is much easier than auditing over-permissioned accounts later.
Seats, and the alternative
On paid plans, members consume billable seats. Adding people therefore has a direct monthly cost, and the cost is per person per month regardless of how much they use it.
This is where the collaborator concept matters. For someone who only needs to look at deploy previews and comment - a designer, a client, a stakeholder reviewing a change - a full team seat is more access and more cost than the job requires.
Check what your plan offers for review-only access before adding someone as a full member. The pattern where an external reviewer needs to see a preview and say whether it looks right is common enough that it is worth solving cheaply, and paying a full seat for it is the expensive way.
Two other cost habits worth adopting. Audit the member list quarterly and remove people who no longer need access - this is the single most reliable way to find money in a team bill. And distinguish between people who need continuous access and people who needed access for one project, because the second group is where seats accumulate silently.
Access that is not a team seat
Several kinds of access do not need a person at all, and using a personal account where a token belongs is a common mistake.
CI and automation. A build pipeline that deploys should authenticate with a token, not with a person’s credentials. A token tied to someone’s account breaks when they leave, and the resulting failure is confusing because nothing about the pipeline changed.
Repository access. Site deploys authorise against your Git provider separately from team membership. Someone can be a team member without repository access, or have repository access and no team membership. Both cause confusion, and both are worth checking when someone reports they cannot deploy.
Deploy previews. Preview URLs are typically reachable by anyone with the link, which is exactly what makes them useful for sharing with people outside the team - and exactly why you should not treat them as private. Anything sensitive on a preview is effectively public.
That last point deserves a moment. Teams routinely build previews against staging data that includes real customer records, then share the URL in a public channel. The preview is not authenticated. Treat preview environments as public unless you have specifically configured access control on them.
The general principle
The pattern here is not specific to one platform. Any hosting platform with team billing presents the same three decisions, and they are worth making deliberately.
- Match the role to the job, not to seniority or to convenience. Most people need site access, not team administration.
- Do not pay a seat for occasional review access. Use whatever lighter mechanism exists - a preview link, a limited role, a collaborator invite.
- Automate with tokens, not accounts. Anything that runs on a schedule or in a pipeline should have its own credential with its own scope.
And the fourth, which applies everywhere: review access periodically. Access grows monotonically unless someone actively prunes it, and the two costs of not pruning are money and a larger blast radius when a credential is compromised.
On RunxBuild, teams work across services, databases, tools, and static sites, with deploy history and runtime logs visible to the team rather than tied to whoever pushed. The same discipline applies: the person who needs to read a deploy log does not necessarily need to change environment variables, and it costs nothing to be deliberate about that from the start.
How this fits the rest of the stack
Team access is one of those costs that grows quietly and is worth pricing alongside the infrastructure it sits on. The RunxBuild hosting calculator shows the service, the managed database, storage, and bandwidth as separate line items on one page, so the platform bill is a set of numbers rather than a subscription you stopped reading. Teams, deploy history, and runtime logs come with it rather than being a tier decision.
Useful related references:
- How to Add an API Key in Netlify Without Publishing It to the World
- Add a User to the Docker Group: Running Docker Without sudo (and the Risk)
- Netlify Forms: What You Get Free, and Where the Ceiling Is
- Database user management on RunxBuild
FAQ
How do I add a user to a Netlify team?
Open the team, go to Members in the left navigation, choose to add a member, enter their email address, select a role, and send the invitation. They accept by signing in with an account matching that address - a mismatch leaves the invitation pending indefinitely.
Do Netlify team members cost money?
On paid plans, members consume billable seats, so each person added has a direct monthly cost regardless of how much they use the account. Roles and seat behaviour vary by plan tier, so check what your plan includes before adding people.
What role should I give a developer?
The role that allows working on sites, triggering deploys, and changing site settings, without team-level administrative access or billing. Reserve Owner for the small number of people who genuinely need billing and member management, and never have only one.
Is there a cheaper way to give someone review access?
Usually yes. For a designer, client, or stakeholder who only needs to view deploy previews and comment, a full team seat is more access and more cost than the job requires. Check what limited or collaborator access your plan offers before adding them as a member.
Are deploy preview URLs private?
Generally not - they are reachable by anyone with the link, which is what makes them useful for sharing outside the team. Treat previews as public unless you have specifically configured access control, and be careful about previews built against real customer data.