Extra accounts for your developers

Your own oN.ftp login can reach every site on your account. That's exactly right for you — and exactly wrong for an outside developer or agency you've hired to work on one site. Handing them your main login would let them see (and change) everything else too, and you'd have to change your own password when the job ends.

There's a better way built in: from the control panel, you can have the system create a separate, limited login — its own SSH, SFTP and FTPS access, with a fenced-in shell like yours but a shorter command list — that reaches only the sites you choose. You stay in control the whole time: you hand over the password yourself, you can force a new password at any moment, and you can switch the whole login off from the panel when the work is done.

How it works: Clients and owners

The control panel has a concept called a Client — a way of saying "this site belongs to this person or company". Extra accounts hang off Clients:

1. Create a Client in your control panel — give it the developer's or agency's name.
2. Edit the site you want them to work on, and set that Client as the site's owner (the Client field on the site's form).
3. Wait a few minutes. The system notices the new arrangement on its next sweep and builds the login automatically — typically within about 3 minutes.

That's the whole setup. The new login's username is your account name plus the Client's name in lowercase letters and numbers — a Client called Acme Corp on account o1 becomes o1.acmecorp. You don't have to work the name out, though: it appears as a file in your account, which is also where the password is (next section).

A few useful rules fall out of this design:

• A site has one owner. You can't attach two Clients (and so two extra accounts) to the same site.
• A Client covers all its sites with one login. Make the same Client the owner of three sites, and its one account reaches all three.
• Separate people should get separate Clients. Everyone using a Client's login is indistinguishable from each other. If you want two developers to have their own credentials — or to be able to cut one off without the other — create a Client for each and split the sites between them.

When the developer logs in, they land in a home directory of their own with a sites folder listing one entry per Drupal (or Backdrop) site they can reach. They get the same limited shell you have, fenced to those sites and their files: the file tools, editors and archivers, Git, rsync/curl/wget for moving files (scp only where your host has enabled it), patch/diff/sed, and the Ruby theme toolchain (gem, bundle, compass, sass), for managing the files and themes of those sites and small custom modules in the site-level space. They do not get Drush, Bee or Composer, database clients or dump tools, the account backup tool, outbound ssh, openssl, the Grav CLI or the Node toolchain, in the shell or over one-shot SSH. Site operations such as clearing caches are done from the control panel, with your own login: Flush all caches on the site does it directly, and Verify also rebuilds a Drupal 8+ site's caches and compiled container. Grav and Textpattern sites are never linked into a sub-account at all: there a site directory is the whole codebase and its database access, so they stay with your main account. They can't see your home directory, your backups, your other sites, or anything belonging to another Client.

Where the password is — and how to send it

The system generates a strong password for the new login and puts it inside your own account, in a folder called users in your home directory. Connect as usual (shell or SFTP) and look at:

~/users/

You'll find one file per extra account. The file's name is the developer's username; the file's content is their password. For the example above that's a file named o1.acmecorp containing a single long password line.

The file only appears once the Client actually owns at least one site — a Client that owns nothing, or whose only site has been deleted, gets no login. (Disabling a site is not enough to switch its owner's login off — see removing access, below.) And nothing is sent anywhere automatically: the system writes the file and stops there. You read it and pass the details to your developer however you prefer — ideally somewhere more private than plain email.

Your developer then connects with:

The same limited-shell rules and the same trick of adding an SSH key (to their account's ~/.ssh/authorized_keys, so they stop typing the password) apply to them too, as described on shell and SFTP access. The command list does not: that page describes your main account, and a sub-account's is the shorter one above.

If they prefer FTPS. Where the host has enabled it (your welcome email lists FTPS when it is), the server also offers FTPS — encrypted FTP — for these accounts. In the file-transfer program choose FTP with explicit TLS (some programs call it FTPES or "Require explicit FTP over TLS") on port 21, with the same username and password. Plain unencrypted FTP is refused, so if a connection fails, check the TLS setting first. SFTP on port 22 is still the simpler choice when the developer's tools support it.

Changing the password

To force a fresh password at any time — say, at the end of a contractor's engagement — delete the password file from your ~/users/ folder:

rm ~/users/o1.acmecorp

Within about 3 minutes the system rebuilds the account with a brand-new password, and the file reappears with the new content. Read it and send it on, as before. A platform-level login (o1.acmecorp-dev, below) has its own file in the same folder and rotates the same way.

Rotation is a rebuild. Deleting the file makes the system remove the extra account completely and create it afresh — that's what guarantees the old password is dead. The developer's own home directory goes with it, including any SSH key they'd added, so they'll need to re-add their key after a rotation. Your sites are never touched: they live in your account, and the extra login only reaches them through links.

The 90-day password expiry you know from your own login applies to extra accounts as well. A key keeps the developer's daily logins working across it, and deleting the password file is the self-service way to issue them a current password whenever one is needed.

Removing access

When the engagement ends, go back to the control panel and delete the Client (or simply take its sites away — change each site's owner, or leave the Client owning nothing). On the next sweep, within about 3 minutes, the extra login is removed completely — SSH, SFTP and FTPS all stop working at once, and its password file disappears from your ~/users/ folder.

One thing that does not cut access: disabling a site. A disabled site still exists and still counts as owned, so its owner's login stays active. To actually end someone's access, delete the Client or change the site's owner, as above.

There's nothing else to clean up. Anything the developer did inside your sites stays exactly where it is — the code and files belong to your account, not to the extra login — and your own credentials were never shared, so there's nothing to change on your side.

Platform-level access for a developer (your host enables it)

An extra account reaches its sites' directories and nothing above them. For a developer who maintains a whole codebase for you — runs Composer, keeps the platform's modules current, works with the platform's own Drush — there is a second kind of login your host can switch on: a platform-level account named oN.<client>-dev, alongside the ordinary one. It is created from a setting only your host can change, so it is never on unless you asked for it. (If you are the developer who received this login, the two sections What your developer sees and can do and Running Drush below are yours; the rest is for the account owner.)

What to ask your host

1. Tell your host which Client the developer works under (the same Client that owns the sites; the developer needs an ordinary extra account first, so the Client must own at least one Drupal or Backdrop site).
2. Your host adds the Client's name to a server setting. Within about 3 minutes a second password file appears in your ~/users/ folder, named like o1.acmecorp-dev, next to the ordinary o1.acmecorp. Forward the username and password as you did for the first one; the developer adds their SSH key to this account's own ~/.ssh/authorized_keys if they want one.

Which platforms it reaches

The account reaches every platform on which all the sites belong to that Client. A platform that also carries anyone else's site — one of yours included, or one owned by the host — is left out, and your host is told which site kept it out; the check runs on every sweep, so moving a site onto or off a platform changes the grant within minutes. If a codebase you want them on holds one of your own sites too, move that site first, or expect the platform to stay out. Grav and Textpattern platforms are never part of it.

What your developer sees and can do

• ~/sites — the same per-site view the ordinary account has.
• ~/platforms/ — one link per codebase they were granted, named after the platform (for example 002-drupal-10.4.10-prod), with a README.txt that repeats the Drush instructions below. The same links show over SFTP.
• The tools: everything the ordinary account has (file tools, editors, Git, rsync and the rest) plus Composer, drush8 for Drupal 7 and Backdrop, drush10/drush11, and vdrush — the platform's own Drush — inside each granted platform.
• What they can write is what you can write with your main login: inside each site, its files/ and private/ folders and the site's own modules/, themes/ and libraries/ folders (the site directory itself, with settings.php, is read-only for every login, yours too); and the whole of any platform you deployed yourself under your account's static/ folder — in the developer's ~/platforms/ those are the links that point under static/ rather than distro/ — where composer update works as on a laptop. A platform installed by the control panel stays read-only for everyone, you included; there the developer reads the code, asks Composer questions, and runs Drush.
• What stays off: database clients and dump tools, the backup tool, and the rest of the list the ordinary account does not have; and a one-shot command sent over SSH (ssh o1.acmecorp-dev@server.example.com "...") keeps the ordinary account's short list, however wide the interactive shell is.

Running Drush on a Drupal 8 or newer platform

Drupal 8+ platforms are kept locked for the control panel's own Drush between uses, and the platform's Drush cannot run while a platform is locked (you may know the lock from the platform recovery cycle). Your developer opens a window:

1. In their shell:

   BASHCopy

   touch ~/.tmp/drush-window.request
   

2. Wait up to 3 minutes. The next sweep unlocks every platform they were granted, for 60 minutes.

3. cd ~/platforms/<name> and run vdrush status (or any vdrush command).

4. Need longer? touch ~/.tmp/drush-window.request again — the hour restarts.

5. At expiry everything is locked again by itself; nothing to do.

Drupal 7 and Backdrop platforms have no lock: drush8 works there at any time.

While a window is open, tasks you run from the control panel on those platforms' sites can fail — the panel's Drush and the developer's cannot drive the same platform at once — and running Verify on a site locks its platform again (the window reopens it on the next sweep). So agree a time with your developer, and keep your panel work off those sites for the hour.

Ending it

Ask your host to take the Client's name out of the setting: within about 3 minutes the login is removed completely and its password file disappears from ~/users/. Deleting the Client, or taking its sites away, ends this login too (see Removing access above), but tell your host as well, so the setting does not go on naming a Client that no longer exists. Everything the developer wrote in your platforms and sites stays where it is — it belongs to your account.

Where to go next

• Shell and SFTP access — what the limited shell allows on your main account, connecting with SFTP, and setting up an SSH key. The SFTP and SSH-key parts apply to extra accounts too; the command list does not.
• When you can't connect — if the new login is refused, the same two culprits apply.
• Managing your sites — the panel-side view of your sites, where the owner is set.