How to Add Team Members with the Right Permissions

Why Access Control Matters

Most teams start with one person holding all the keys. Then a contractor needs to push a fix, a support hire needs to restart a service, or a new developer needs to see logs — and the fastest option is always the same: hand over the root password or add them to every server as a full admin. It works, right up until it doesn't.

Full access means a junior developer testing a deploy script can drop a production database, a departing contractor can still SSH in six months later, and nobody can tell from the logs who actually ran the command that took the site down. None of this is hypothetical — it's the default outcome of treating "team access" as a single on/off switch instead of something you scope per person and per resource.

The fix isn't more trust, it's better defaults. Access control that's designed around roles — what someone actually needs to do their job — catches the mistake before it happens instead of relying on everyone remembering to be careful. That's true whether you're running one server for a side project or a dozen for client work; the difference is just how painful it is to bolt permissions on after the fact versus setting them up correctly from the first invite.

Inviting a Team Member

In CloudStick, adding someone to your team doesn't mean giving them SSH credentials at all. From the Team section of the dashboard, you send an email invite, the teammate accepts and creates their own login, and from that point on they authenticate as themselves — never as you, and never with a shared root password sitting in a password manager somewhere.

How many teammates you can invite depends on your plan: the Free plan doesn't include team seats, Basic includes 2, Pro includes 4, and Business includes 10. If you're consistently hitting that ceiling, it's usually a sign it's time to move up a tier rather than start sharing logins to work around the limit.

The invite itself is the easy part. The decision that actually matters — and the one teams skip — is what that invite should grant access to before you send it.

Scoping Permissions by Server and Website

Role-based access control means a teammate's permissions are defined by what they need to do, not by whether they're trusted in general. A support engineer who needs to restart a stuck WordPress site doesn't need database credentials for the billing server. A freelance developer working on one client's site doesn't need visibility into every other client you host.

A practical way to scope roles: give deploy access (push code, restart services, view logs) to developers actively working on a site; give read-only access (view metrics, logs, uptime) to anyone who just needs visibility, like a client or a project manager; and reserve full server-level access — provisioning, firewall rules, adding new websites — for the people actually responsible for the infrastructure. Most teams need far fewer full admins than they think.

The Manual Linux Alternative

Without a control panel, scoping access means doing it at the operating system level: a real Linux user account per teammate, plus sudo rules that limit exactly which commands that account can run as root. On Ubuntu 22.04 and 24.04, that looks something like this:

That's workable for one server and one teammate. The problem is it doesn't scale: adding `devuser` to the full sudo group with usermod -aG sudo devuser instead of writing a scoped sudoers file is the shortcut most people take under time pressure — and it grants root, full stop. Do this across five servers for four teammates and you've got twenty separate user accounts, twenty sets of SSH keys to rotate, and no single place to see who has access to what, or to revoke it all when someone leaves.

Common Mistakes to Avoid

A handful of patterns cause most team-access incidents, and they're almost always convenience decisions made under deadline pressure:

Sharing one login across multiple people. It feels efficient, but it erases accountability entirely — when something breaks, there's no way to tell which of three people using the same account did it. Defaulting everyone to admin because scoping access "takes too long." It takes longer to audit and revoke later. Forgetting to remove access when someone leaves or a contract ends — this is the single most common source of stale credentials sitting on a server months after they should have been deleted. And granting server-wide access for a website-specific task, which means one compromised or careless account can now touch every site on that box, not just the one it was meant for.

The fix for all four is the same habit: scope access to the smallest set of resources that lets someone do their job, and treat removing access as part of offboarding, not an afterthought.

It also helps to review access periodically instead of only at onboarding and offboarding. Teams change scope over time — a developer who joined to work on one client site often ends up touching two or three more within a few months, and nobody goes back to check whether that expanded access was ever intentional. A quarterly pass through your team list, matching each person against what they're still actively working on, catches the accounts that quietly outgrew their original purpose.

Next Steps

Before you invite your next teammate, write down two things: which servers or websites they actually need to touch, and what they need to do there — deploy, view, or administer. That short list is the entire basis for scoping their access correctly, whether you're doing it through a dashboard invite or a hand-written sudoers file.

If you're still sharing one root login across your whole team, that's the first thing to fix — not the last. Every additional day it continues is another day without a real answer to "who did this?" when something goes wrong.