Sooner or later someone else needs into your Cloudflare account. It might be a freelance developer fixing DNS, an agency running your WAF rules, or a teammate deploying Workers. The worst way to handle it is to share your login. The right way is to invite them as a member and give them only the access they need.
In this CodeROG tutorial you’ll learn how Cloudflare’s permission model works, how to invite a member step by step, how to limit someone to a single domain, and when to use an API token instead of a person.
Why you should never share your Cloudflare password
Sharing one login means everyone has full control: billing, DNS, SSL, and the power to delete your zones. You can’t tell who changed what, and you can’t remove one person without changing the password for everyone. If you’ve already set up two-factor authentication, sharing also means sharing your 2FA device, which defeats the point.
Cloudflare’s member system fixes all of this. Each person signs in with their own account, gets their own permissions, and can be removed in two clicks.
How Cloudflare permissions work
Cloudflare builds access from three pieces. A policy combines an actor (the member), a scope (what they can touch) and one or more roles (what they can do there).
| Piece | Question it answers | Examples |
|---|---|---|
| Member | Who? | [email protected] |
| Scope | Where? | Whole account, one domain, a domain group, a single Worker or Access app |
| Role | What can they do? | Super Administrator, Administrator Read Only, DNS, Firewall, Cache Purge |
There are three kinds of scope:
- Account scope applies across the whole account and every domain in it.
- Domain scope limits access to one domain, or to a domain group such as “all production sites”.
- Resource scope limits access to one item, such as a single Worker, R2 bucket or Access application.
Each scope only accepts its own set of roles. A member can hold several policies, and their total access is the sum of all of them.
Before you start
- You must be a Super Administrator on the account.
- Your email address must be verified.
- Know the email address the person will use to sign in to Cloudflare.
- Decide what they actually need. “Fix a DNS record on one site” is a very different grant from “manage everything”.
If your site isn’t on Cloudflare yet, first connect your domain to Cloudflare.
Step-by-step: invite a member to your Cloudflare account
- Log in to the Cloudflare dashboard and select your account.
- Go to Manage Account > Members (direct link: Members page).
- Select Invite members.
- Enter one or more email addresses, separated by commas.
- Create the first permission policy:
- Choose a scope: the entire account, or specific resources such as a domain, Worker or Access application.
- Select one or more roles. You can search by name or tick a whole category.
- Select Create policy.
- Optional: add more policies with different scopes or roles. For example, DNS on site A plus read-only on site B.
- Review the summary and select Invite members.
The person gets an email and shows as Pending until they accept. On Enterprise plans you can choose Skip email confirmation to add someone who already has a Cloudflare account directly. Cloudflare’s official walkthrough is in Manage account members.
Limit a member to one domain (domain-scoped roles)
This is the most useful trick for agencies and freelancers. Instead of account-wide access, give someone control of a single site.
- In the invite or edit screen, set the scope to Specific domain with the operator Include.
- Pick the domain.
- Choose domain roles such as DNS, Firewall, Cache Purge or SSL/TLS.
The member now can’t see or change your other domains. If you manage many sites, create a domain group (for example “Staging sites”) and scope policies to the group. Cloudflare introduced this in its Domain Scoped Roles announcement, and a common use is keeping production locked to a few people while staging stays open.
Need a refresher on records the member will be editing? See Cloudflare DNS records explained.
Which role should you give?
Use the principle of least privilege: start small and add access when it’s needed.
| Who | Suggested scope | Suggested role(s) |
|---|---|---|
| Co-owner or business partner | Account | Super Administrator |
| Developer fixing DNS on one site | One domain | DNS |
| Security agency | One domain or domain group | Firewall, Bot Management |
| Content team clearing cache | One domain | Cache Purge |
| Auditor or accountant | Account | Administrator Read Only, Billing |
| Developer deploying one Worker | One Worker (resource) | Workers role for that resource |
Keep at least two Super Administrators so you’re never locked out, and treat that role like the keys to the building. Role names vary by plan; check the full roles list in your dashboard.
Manage teams with User Groups
If several people need the same access, use User Groups. Assign a policy once to the group, and every member in it inherits that access.
- Go to Members and open the Groups tab.
- Select Create a Group and give it a name, such as “Agency – DNS team”.
- Under Permission policies, add a policy with the scope and roles you want.
- Add members to the group.
One catch: permissions inherited from a group don’t show on the Members page. To see someone’s full access, check both their direct policies and the groups they belong to. Enterprise teams can also sync groups from Okta or Entra ID with SCIM.
Delegate access to a script or service: API tokens
Sometimes the “someone” is a CI pipeline, Terraform, or a deploy script. Don’t give it a person’s Global API Key. Create a scoped API token instead.
| Token type | Owned by | Best for | Where to create |
|---|---|---|---|
| User API token | One person | Personal scripts and tools | My Profile > API Tokens |
| Account API token | The account | CI/CD, Terraform, long-lived integrations | Manage Account > API Tokens |
Account API tokens act as service principals. They keep working if the person who created them leaves, while a user token is revoked when its owner leaves the account. Only Super Administrators can create them. Not every endpoint supports account tokens yet, so check the compatibility list first.
To create one: go to Manage Account > API Tokens, select Create Token, pick a template or custom permissions, limit it to the zones it needs, and copy the secret once. This pairs well with automated deploys; see deploy a site with Cloudflare Pages.
Edit or remove access
- Change permissions: Members > … on the person’s row > View & Edit permission policies. Add, edit or delete policies.
- Block API access: … > Manage member settings > choose Block access.
- Resend an invite: … on a Pending member > Resend invite.
- Remove someone: … > Remove member, then confirm. Do this the day a contract ends.
If you’re the one leaving an account, invite a replacement Super Administrator first, then select Leave account on your own row.
Security checklist
- Never share your Cloudflare password or Global API Key
- Give each person their own member login
- Scope contractors to specific domains or resources
- Keep two or more Super Administrators
- Ask every member to enable 2FA
- Use account API tokens for automation
- Review the Members page and Groups tab every quarter
- Remove access as soon as work ends
Wrapping up
Delegating Cloudflare access takes five minutes and saves you from the risks of a shared login. Invite people as members, scope them as tightly as the job allows, group them when teams grow, and give machines their own tokens.
Found this useful? Browse more CodeROG tutorials or subscribe to the CodeROG YouTube channel for the video walkthrough.
Further reading (official docs):
