Letting someone in without handing over the account

A designer needs to upload a theme. A writer needs a mailbox on one domain. A contractor needs to read files in one folder for three weeks. The quick answer is to send them the cPanel password, and it is the wrong one, because that password opens every site on the account and cannot be taken back from one person.

User Manager gives each of them a login scoped to what they actually need.

What a scoped user gets

• Email at an address on the account, with its own quota.
• FTP limited to a directory you name.
• Web disk access to a folder over WebDAV.

Switch on only what the job needs. A writer with a mailbox does not need file access; a designer with file access does not need a mailbox.

The form itself takes under a minute and the video above runs through it. Two fields on it are worth thinking about before you start: the generated password, which you should never replace with one you invented, and the directory, which is where the actual boundary gets drawn.

The directory field is the whole point

Left at the account root, an FTP or web disk user can read and change every site sharing that account. Set to the one folder they work in, everything else is invisible to them.

On a network this is the difference between a contractor who can touch one client's theme and a contractor who can touch all of them. It is a single field and it is the one most often skipped, because the form works without it.

One person, one user

Resist the shared login. Two people on editor means you cannot remove one of them, and when something is changed unexpectedly the logs tell you the account name rather than the person. Separate users cost nothing and make both problems go away.

Removing access is the part that gets forgotten

Create users freely; the risk is not creating them, it is leaving them. A user added for a two week job and never removed is a live credential nobody is thinking about, and on an estate these accumulate quietly across accounts.

Two habits help. Put the reason and an end date in the person's full name field, so the list reads like a set of commitments rather than a set of names. And when a project closes, delete the user in the same sitting as the final invoice, not "later".

What it does not cover

• Not a panel login. They cannot open cPanel itself, only the services enabled.
• Not database access. That is granted separately per database user.
• Not shell. Shell access uses keys and is a different decision entirely.

If what the person really needs is to move a lot of files rather than a standing login, a temporary FTP account pointed at one folder may be the smaller commitment.