Skip to main content

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.

Next

  • Logs — reading what your application wrote
  • Backups — before you import anything over production