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.
With the Vallic CLI
The Shell access card shows these commands first. The CLI works out the host, the port and the account for you, and gets the quoting right. Forty more, from deploying to domains, are on The Vallic CLI:
curl -fsSL https://raw.githubusercontent.com/Vallic/vallic-cli/main/installer.sh | bash
vallic login
vallic ssh staging |
A shell. vallic ssh staging -- drush cr runs one command |
vallic mount upload staging ./files |
Copies a local directory into the public files directory |
vallic mount download staging ./files |
And back down |
vallic mount upload staging ./private --area private |
The same for private files, or a mount: --area mounts/<name> |
vallic mount list staging |
Every area the environment has, by the name --area takes |
vallic db import staging < dump.sql |
Replaces the database with a dump |
vallic db export staging > dump.sql |
Takes a copy of it |
vallic sql staging |
An interactive database prompt |
vallic tunnel staging db |
A local port onto the database, for a desktop client — see Tunnels |
The card adds --project with your project's machine name —
vallic ssh production --project acme-webshop — so its commands work from
any directory. Inside your project's checkout it can be left off: the project
comes from the git remote, and leaving the environment's name off as well
picks the one tracking your current branch.
The installer checks the download against a checksum the platform publishes,
and installs nothing if it does not match. The CLI uses the same keys and the
same access as plain SSH below; it adds nothing a key would not reach.
Logging in
Plain SSH works without the CLI. The card shows the command with everything filled in, under Plain SSH:
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 -t -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. Keep the-t: ssh treats the name as a command, and gives a command no terminal unless it is asked to, so without it the shell opens and shows nothing. 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.
Several machines, and workers
An environment on more than one machine — a dedicated one, or one with a
service on a machine of its own — answers at one address: its front. The login
is carried on from there to the machine you name, over the environment's
private network, and you log in there with the same key. The Shell access
card lists a line per machine; by hand it is ssh's ProxyCommand:
ssh -t -o ProxyCommand='ssh -p 2417 vc-t-acme@production.gwfdxo99.vallic.cloud jump web-2' -p 2417 vc-t-acme@web-2.production.gwfdxo99.vallic.cloud
Where the front runs no site of its own — a load balancer, or Varnish on its own machine — the card's plain login already goes on to the first web server.
A worker runs in a container of its own, named worker-<name>-<n> after
the worker in vallic.yaml — worker-queue-1. Put its name after @ to open
it instead of the site's: ssh -t … @worker-queue-1, on the worker machine
where the environment has one. The CLI takes the short name and finds the
machine: vallic ssh production --container queue-1. The workers are listed on
the card, and asking for one that is not on that machine lists what is.
Copying files
Each environment keeps three directories, separate from each other, and all of them outlive every deploy:
| Directory | What it holds |
|---|---|
/mnt/files/public |
Files the web serves directly — Drupal's sites/default/files |
/mnt/files/private |
Files served only through your application's access checks |
/mnt/files/mounts/<name> |
The extra directories your vallic.yaml lists under mounts |
vallic mount upload and vallic mount download reach every one of them:
public by default, the others with --area private or --area mounts/<name>.
Without the CLI, rsync straight into the directory:
rsync -avz -e 'ssh -p 2417' ./files/ vc-t-acme@production.gwfdxo99.vallic.cloud:/mnt/files/public/
rsync -avz -e 'ssh -p 2417' ./private/ vc-t-acme@production.gwfdxo99.vallic.cloud:/mnt/files/private/
Never copy private files into public: anything there can be fetched by its
URL. The other way round takes 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.
Tunnels to your services
vallic tunnel opens a port on your own computer that reaches one of your
environment's services, so a desktop client can connect to it: a database tool,
a Redis or Solr browser, curl against Varnish.
vallic tunnel staging db # whichever database the stack runs, on 127.0.0.1:3306
vallic tunnel staging redis # 127.0.0.1:6379
vallic tunnel staging solr # http://127.0.0.1:8983/solr
vallic tunnel production db --port 13306
| Service | Name | Local port |
|---|---|---|
| The database | db (or mariadb, mysql, postgres) |
3306, or 5432 for PostgreSQL |
| Redis or Valkey | redis, valkey |
6379 |
| Memcached | memcached |
11211 |
| Solr | solr |
8983 |
| Meilisearch | meilisearch |
7700 |
| RabbitMQ | rabbitmq |
5672 |
| Varnish | varnish |
6081 |
--port chooses another local port, for when the usual one is taken or you
have tunnels to two environments open at once. Ctrl-C closes the tunnel.
The credentials are your environment's own. For the database:
vallic ssh staging -- printenv DB_NAME DB_USER DB_PASSWORD
A tunnel reaches only the service you name, of the environment you name, on its
own port: each connection is one SSH session that the machine hands to that
service. It works where the service runs on the same machine as your site; a
database on a machine of its own is reached with vallic sql and vallic db.
Who may open one is who may open a shell — below.
What is not allowed
No SSH port or agent forwarding. ssh -L and ssh -A are refused: an
address and port of your own choosing would be a way past everything on this
page that decides who reaches what. vallic tunnel is the way to reach a
service from your computer.
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.