Cloud docs
Shell access
Logging in to an environment over SSH, copying files and databases in and out, and what the shell can and cannot reach.
Every environment can be reached over SSH, into the container your site runs
in. It is how you run drush, look at a file your application wrote, or move a
database from somewhere else.
#Before you start
Add an SSH key to your account — Your keys on the environment's Shell access card, or SSH keys on your account. Keys belong to you, not to a team: one key reaches every environment you are allowed a shell on, across all your teams, and removing it removes it from all of them.
| Accepted | Refused |
|---|---|
| Ed25519 | DSA |
| ECDSA (256, 384 or 521 bits) | RSA under 2048 bits |
| RSA of 2048 bits or more | Hardware security keys (sk- types) |
Ed25519 is the one to generate if you are making a new key. A key can only be on one account.
A new key reaches the machines within a minute or so of saving it; the card says so until you have one.
#Logging in
The Shell access card on the environment shows the command with everything filled in:
ssh -p 2417 vc-t-acme@production.gwfdxo99.vallic.cloud
- The host is the environment's platform hostname — never your own domain, which may be behind a CDN that does not carry SSH.
- The port belongs to the project. Every environment of the project uses
the same one, and it does not change. It is not 22, so remember
-p, and-e 'ssh -p …'for rsync. - The user is your team's account on the machine. It is the same for everyone on the team: which person you are is decided by your key.
- Staging and development add the environment's name after the host —
ssh -p 2417 vc-t-acme@staging.gwfdxo99.vallic.cloud staging. They share one machine and the project's port, so the port alone does not say which you meant; the name does, and is taken off before anything runs. For a command, put it after the name:… staging db-export. For rsync, pass it as--rsync-path='staging rsync'. Without a name where one is needed, the login is refused with the choices rather than guessed. Production needs none.
If you have several keys loaded, SSH may offer the wrong ones first and be turned away before it reaches the right one. Name it:
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 -p 2417 vc-t-acme@production.gwfdxo99.vallic.cloud
#Where you land
Inside the site's application container, as the user the site runs as — not on the machine. Your code, your files and your database are all within reach; the host, other containers' internals and other customers are not.
| Path | What it is |
|---|---|
/var/www/html/current |
The live release. Read-only |
/mnt/files/public |
Your application's files. Writable, and what survives a release |
/var/log/app |
Your application's own log files — see Logs |
The release is read-only because it is the artifact that was built and deployed. A fix edited in place would be gone on the next deploy and would never have been in git; make it in the repository.
drush is your project's own, from its vendor/bin, so it is always the
version your site was built with. The same goes for anything else your build
puts in vendor/bin or bin. WP-CLI is not provided — add it to your
build if your WordPress site needs it.
If the environment has never been deployed, there is nothing to log in to yet, and the shell says so.
#Copying files
rsync, straight into the files directory:
rsync -avz -e 'ssh -p 2417' ./files/ vc-t-acme@production.gwfdxo99.vallic.cloud:/mnt/files/public/
and the other way round to take a copy out. scp works too, with scp -O
on a recent OpenSSH, which otherwise speaks SFTP by default. SFTP itself is
not available, so a graphical SFTP client will not connect.
#Databases
Three commands, run in the database container rather than your application's, so the right client is always there:
| Command | Does |
|---|---|
db-export |
A dump of the environment's database, to standard output |
db-import |
Loads a dump from standard input |
db-cli |
An interactive mysql or psql prompt |
Used from your own computer, over SSH:
ssh -p 2417 vc-t-acme@production.gwfdxo99.vallic.cloud db-export > dump.sql
ssh -p 2417 vc-t-acme@production.gwfdxo99.vallic.cloud db-import < dump.sql
db-import loads over what is there. On production that is your live site;
take a backup first. To bring another environment's data into
staging, Copy from another environment under Backups is usually the better
route, because it runs your sanitisation commands.
#What is not allowed
No port forwarding, tunnels or agent forwarding. You cannot open a tunnel
to the database and point a desktop client at it — db-cli is the way in. A
tunnel would be a way past everything else on this page that decides who
reaches what.
A connection that stops answering is dropped after about three minutes. Five failed logins from one address within ten minutes blocks that address for an hour.
#Who can use it
Developer and above, on every environment, production included. The shell is part of operating a site; the protection on production guards reshaping it, not working on it. Viewers get no card and no access.
Access follows your role: a person narrowed to certain projects reaches only those, and a suspended team loses shell access along with everything else above Viewer.
Every login is recorded on our side — who, from which address, to which environment, and for how long. What is typed inside a session is not. The record is not shown in the console.