How to Set Up Role-Based Access for Your Team

Why Shared Root Access Breaks Down

The moment a team grows past one person, a single root password stops working as an access model. Every teammate who can SSH in as root can also drop a database, delete a website's document root, or revoke another admin's access by accident — there's no boundary between "can restart PHP-FPM" and "can wipe out a client's site." Role-based access fixes this by giving each teammate only the permissions their job actually requires, scoped to only the servers or websites they work on.

This isn't about distrust. It's about limiting the blast radius of a mistake. A support engineer who only ever needs to restart a service or tail a log file shouldn't also have the ability to delete a database, and a contractor brought on for one client's WordPress site shouldn't be able to see the other twelve sites running on the same server.

Roles vs Permissions

A role is a named bundle of permissions — Owner, Admin, Developer, Viewer — and a permission is a single capability, like restarting a web server, editing DNS records, or pulling a database backup. Separating the two means you're not writing a custom permission set for every new hire.

An Owner has full account control: billing, adding or removing team members, and access to every server. An Admin can manage servers and websites but typically can't touch billing or remove the account owner. A Developer-level role covers the day-to-day — deploying code, managing PHP versions, restarting services, viewing logs — without server-deletion rights or access to raw SSH credentials. A Viewer role is useful for clients or stakeholders who need visibility into uptime and deployments but shouldn't be able to change anything.

The real value of roles over raw permissions is maintainability: when someone changes jobs internally, you change their role once instead of auditing every individual permission they've accumulated over months.

Scoping Access by Server or Site

Roles answer "what can this person do," but scope answers "where can they do it" — and scope is usually the more important control. A teammate assigned to fix a plugin conflict on one WordPress site has no legitimate reason to see a different client's billing details, database credentials, or the other servers on the account.

CloudStick lets you scope a teammate's access to one server or one website instead of the whole account, so a junior developer fixing a WordPress plugin issue never sees the client's billing information or any of your other servers. You invite them, assign a role like Developer, and restrict the assignment to the specific server or site they're working on — the rest of the account simply doesn't exist from their point of view. Seat limits scale with plan, from zero extra seats on the free tier up to ten on Business, so the scoping model has to work whether you're a two-person shop or running a full agency team.

This matters most for agencies managing sites across multiple clients on shared infrastructure, where an overly broad invite is effectively a data-exposure incident waiting to happen.

The Manual Linux Approach

Before any of this existed as a dashboard feature, teams built the same idea by hand with Linux system users and sudoers rules — and it still works if you're managing a small number of servers directly. Start by creating a dedicated system user for each teammate rather than sharing one root login:

Then scope exactly what that user can run as root using a dedicated file in /etc/sudoers.d/, edited with visudo so a syntax error can't lock you out of sudo entirely:

This gives jsmith the ability to restart exactly two services as root and nothing else — no database access, no user management, no ability to touch other users' files. The problem is scale: that sudoers file has to be created and maintained per user, per server. Add a fifth server and you're copying the same allowlist by hand and hoping every server stays in sync. Remove a contractor and you have to remember every server they had a sudoers file on and delete each one — miss one, and they keep access indefinitely.

Setting Up Roles Step by Step

The setup takes five steps regardless of which system you're using to manage it:

1. Decide on your role tiers before inviting anyone — Owner, Admin, Developer, Viewer covers most teams without over-engineering it.
2. Invite each teammate individually rather than sharing credentials, so any single person's access can be revoked without affecting anyone else.
3. Assign the role that matches their actual job, not the broadest one that's convenient in the moment.
4. Scope the assignment to the specific server or website they need, not the whole account.
5. Revisit assignments on a schedule, or immediately when someone changes roles or leaves.

Keeping Access Current

Role-based access isn't a one-time setup — it needs to be revisited every time your team changes. Offboarding is the moment this pays off: removing someone from a role-based system takes one click and instantly revokes their access to every scoped server and site, while the manual sudoers approach means SSHing into every server that person ever touched and deleting their user and sudoers file one by one.

A short checklist keeps this from slipping: review role assignments on a regular schedule, not just when something breaks; revoke access the same day a contractor's engagement ends; keep Owner-level roles to the smallest number of people possible; and scope every new invite to a specific server or site by default, widening it only when there's a clear reason to.

Get this right once and adding the fourth, fifth, or tenth teammate to your infrastructure stops being a security decision made under time pressure — it's just filling in a role and a scope.