How do I give a freelancer or client access to my website host without handing over everything?

This page may contain affiliate links from which Blur Studio earns commissions.

Sharing your main login with a freelancer or client, even through a password manager, is one of the more common small-business security shortcuts, and it's worse than it looks: it gives full account access by default, there's no record of who actually changed what, and revoking access later means changing a password everyone who had it was relying on. Netlify's own team roles exist specifically to avoid this, letting you give someone exactly the access their actual job needs.

The actual roles, and what each can do

Netlify's roles include Team Owner (full control over the account, billing, and all settings), Developer (can deploy and manage sites but without the account-level controls an Owner has), Reviewer (can review and approve things like deploy previews without broader site-management access), and Publisher (can publish or roll back deploys). This maps naturally onto real situations: a freelance developer gets Developer access to actually do the work; a client who just needs to approve a preview before it goes live gets Reviewer access and nothing more; someone responsible for actually pushing approved changes live gets Publisher.

What actually requires a paid plan

The Free plan is built around a single person managing the account, with little reason to apply role distinctions since there's generally nobody else to assign a role to. Real role-based access starts on a paid plan: Pro includes unlimited team members, and Reviewers specifically are listed as unlimited on paid plans generally, meaning you can bring in as many reviewers as you actually need without per-seat cost concerns on that specific role. If you're currently on Free and sharing a password because the account only supports you, that's actually the core problem, not something to work around: upgrading to a paid plan is what unlocks giving people their own properly scoped access in the first place.

Step by step: setting up scoped access

1. Confirm you're on a paid plan, since Free doesn't support additional team members with roles at all.
2. Decide what the person actually needs to do: build and deploy (Developer), review and approve (Reviewer), push live changes (Publisher), or genuinely everything (Owner, rarely the right choice for an outside contractor). Reviewers can approve work as described ingetting client approval on a real website.
3. Invite them from your team settings with that specific role, using their own email, not a shared login.
4. Revoke access when the engagement ends by removing them from the team, which is a clean, instant action rather than the awkward process of changing a shared password everyone else was also using.

What Enterprise adds on top

For larger teams or agencies managing many client sites, Enterprise adds single sign-on (SSO) and SCIM for centralized identity management, organization-wide controls, log drains for exporting activity to your own monitoring, a 99.99% uptime SLA, 24/7 support, and deploy history retention extending well beyond lower tiers. This is overkill for a single freelancer relationship, but genuinely useful once you're managing access across many team members or client accounts at once and want it centrally controlled rather than managed site by site. Agency billing is covered inNetlify for agencies.

Why the shared password habit is worse than it feels

A shared password feels convenient in the moment: no setup, no plan upgrade, just hand over the credentials. The real cost shows up later. There's no record of who made a specific change if something breaks or looks wrong. Revoking access means changing the password for everyone who had it, which is disruptive if multiple people are actively using it. And it almost always grants more access than the person actually needs, since a shared account login has no concept of "just let them review, not publish."

A worked example: a messy handoff between two freelancers

A small business owner had shared her Netlify login with a freelance developer over a year earlier, stored in a password manager entry labeled simply "website." When that developer moved on and a new one was brought in, the owner updated the shared password and sent the new credentials to the new developer, assuming that was a clean handoff. Several weeks later, the site broke after a deploy, and nobody could figure out who'd made the change or when, since the activity log showed only "owner account" for every action regardless of which developer had actually been logged in at the time.

It later turned out the first developer still had the old password saved somewhere and had made one more change after being told the engagement was over, confusion about whether they still had informal "just fix this one thing" permission that a scoped account would have made explicit and unambiguous from the start. Switching to proper roles after that incident meant each developer got their own Developer-level account under their own email, and when the engagement ended, removing them from the team instantly and verifiably cut off access, with the account's own activity log finally showing which specific person made which specific change going forward.

A practical note on making offboarding a standing habit, not a one-off cleanup

A useful habit for any business working with multiple contractors over time: whenever a project wraps up, removing that person's access is part of the actual close-out, the same way you'd confirm a final invoice is settled, rather than a separate task someone has to remember weeks later. Businesses that treat access removal as automatic at project close tend to have far fewer stale accounts lingering than ones that only clean up access when someone happens to notice an old contractor is still listed. A quarterly check of the full team member list, even a quick five-minute scan, catches whatever slips through that habit. For drafts, see how toshow a draft website to a client without Google finding it.

What I'd actually tell you

If you're currently sharing a password with a freelancer or client because your plan only supports one account slot, treat upgrading to a paid plan as the actual fix, not an optional nice-to-have, since the cost of a paid seat is small compared to the real risk of an unscoped shared login, especially once more than one outside person has had access to it over time. Give people the narrowest role that lets them do their actual job, and remove access the moment the engagement ends. An invite-only page is another way to share, as ina private page for partners or dealers.

How I'd approach this

When I take on a client's site, I ask for the most limited role Netlify's team settings allow that still lets me do the work, Developer access rather than full Owner access, as a matter of course, and I'd encourage any client to do the same with every contractor they work with. It costs nothing extra beyond the plan you're likely already on, and it means you always know exactly who had access to what, and can remove it cleanly the moment you need to.