Logins, roles & team access — Cheat Sheet

Hand every colleague their own key, never yours. This page is the quick primer: which login fits which person, the two control-panel roles, the two shell logins a Client can have, the one rule about Drush and the database, and how to rotate or cut someone off — with a plain word on which steps are yours and which are your host's. Everything here links to the full story.

Team access in 30 seconds

Your own two logins are never shared — your control-panel login and your oN.ftp shell reach everything on the account. → The six kinds of login
The Client is the fence — every colleague login, panel or shell, sees only the sites of the Client it belongs to, so decide the Client first. → What every colleague login has in common
Two panel roles — Client runs every site task, backups and the admin login link included, but can't delete a site; Site operator runs the day-to-day tasks with no database copy, admin login or deletion. → Control-panel logins and their roles
Two shell logins per Client — oN.<client> for files and themes builds itself; oN.<client>-dev for whole codebases is switched on by your host. → Shell logins
The database line — Drush on a site means its whole database plus an admin login, so it goes only to someone you'd also give the Client role. → Who should hold what

Draw the fence first: one Client per team

Create a Client in your control panel named after the developer or agency, and set it as the owner of each site they work on (the Client field on the site's form). One Client covers all its sites with one shell login, so give separate people separate Clients — you can't cut one off without the other otherwise.

Never attach a colleague to the Client named admin: everything on the account is shared with it, so its members see every site, task and Client.

→ Clients and owners · Clients: who owns what

A colleague in the control panel: Client or Site operator

Pick the role by trust. Client can run every task on its Client's sites — Verify, Backup, Restore, Clone, Migrate, Reset password, the Export and Get buttons — so give it to someone you'd trust with a copy of every database and the admin account of every site. Site operator still clones, migrates, verifies, clears caches and switches sites off and on, but gets no backup, export, admin login or deletion.

Your host creates the login and gives it the role: tell them the name and email, Client or Site operator, and which Client the person works under. You can attach an existing login yourself on the Client's edit form ("Associate a user to this Client"). Every task records who queued it, for the life of the site.

→ The Client role · Getting a colleague a login

Once a Client owns a Drupal or Backdrop site, the server builds a separate shell login for it within a few minutes — your account plus the Client's name, so Acme Corp on o1 becomes o1.acmecorp — and leaves its password in your own ~/users/ folder. Nothing is sent anywhere; you forward it:

BASH

ls ~/users/                 # one file per extra login: the name is the username
cat ~/users/o1.acmecorp     # ...and its content is the password you forward

It reaches the files and themes of that Client's sites and nothing else — no Drush, Composer or database tools — which makes it the login that fits beside a Site operator panel login.

→ Where the password is · Shell & Drush cheat sheet

For a developer who maintains a whole codebase with Composer and the platform's own Drush, your host can switch on a second login for the same Client, oN.<client>-dev: tell them which Client, and its password appears in your ~/users/ within about three minutes. It reaches every platform on which all the sites belong to that Client.

Drush on a site is full access to its database plus an admin login on demand — the same power the Client role holds through Backup, Export and Reset password. So give it only to someone you'd also give the Client role, and never beside a Site operator login.

→ Platform-level access for a developer · Who should hold what

Rotate, detach, cut off

To detach a panel colleague, use the Remove column on the Client's edit form — their view of your sites ends on the spot. To give a shell login a new password, delete its file; it's rebuilt with a fresh one within a few minutes (any SSH key they added goes with it, your sites are untouched):

BASH

rm ~/users/o1.acmecorp

To end a shell login for good, change each of its sites' owner (or delete the sites); to end a developer login, ask your host to take the Client off it. Disabling a site doesn't cut access — a disabled site still counts as owned.

→ Changing the password · Removing access

They need to…	Give them	How it's set up
Run every site task, backups and exports included	A panel login with the Client role	Your host creates it and attaches it to your Client (or you attach it on the Client's edit form)
Operate sites day to day, no database copy or deletion	A panel login with the Site operator role	Your host creates it and attaches it to your Client; it sees only that Client's sites
Edit files and themes over SFTP or SSH	`oN.<client>`	Built automatically; the password lands in your `~/users/`
Maintain a whole codebase with Composer and Drush	`oN.<client>-dev`	Your host switches it on, per Client, when you ask

With your own two, that makes six kinds of login — all compared in the who-can-do-what matrix.

If something's weird

A colleague's new panel login sees no sites at all → a login needs both a role (your host sets it) and membership of a Client (the Client's edit form). Getting a colleague a login.
A colleague suddenly sees every site on the account → they were attached to the Client named admin; remove them there and attach them to your own Client. Getting a colleague a login.
A contractor's shell login still works after you disabled their site → a disabled site still counts as owned; change the site's owner, or delete its password file to kill the old password. Removing access.

Going deeper

The whole topic, in depth: Logins and roles — all six kinds of login, the who-can-do-what matrix and the password lifecycles.
Both shell logins, step by step: Extra accounts for your developers.
The shell side: Shell & Drush cheat sheet · getting back in: Password and access problems.
The role matrix and how your host creates a login (for operators): Control-panel roles and logins · Platform developer account.