db-prod-import, ssh-prod... more DDEV commands to pull remote databases

In a previous post, I introduced db-import and db-export, two global DDEV commands to manage database dumps locally. That left the chore that comes before: getting the production dump. SSH into the server, drush sql-dump, scp, import… always the same steps, rewritten in a Makefile or a script specific to each project. 

So here is the logical follow-up: "remote server" commands, also dropped into ~/.ddev/commands/host/ and therefore available in all DDEV projects on the machine: db-prod-dump, db-prod-get, db-prod-import and ssh-prod, plus their counterparts for the staging environment, db-preprod-* / ssh-preprod.

The end goal fits in one line: type ddev db-prod-import in any project and end up logged into my local site with a freshly imported production database. And the whole thing is now packaged as a DDEV add-on: ddev-drupal-tools.

It's actually a port of my small project https://github.com/kgaut/drupal-makefile, which I was still using before switching to these DDEV commands.

It all starts with the project's .env

The commands are global, but each project has its own server, path and drush. All the configuration is therefore read from the .env file at the project root, with a prefix per environment (PROD_ or PREPROD_):

# project .env
PROD_USER=kevin
PROD_HOST=mon-serveur.example.org
PROD_PORT=22                           # optional, defaults to 22
PROD_PATH=/var/www/monprojet           # project root on the server
PROD_DRUSH=vendor/bin/drush            # drush binary, relative to PROD_PATH
PROD_DB_PATH=/var/www/monprojet/dumps  # dumps directory, on the server
PROD_URL=monprojet.example.org         # used to name the dump files

# same idea for staging, with the PREPROD_ prefix
PREPROD_USER=kevin
PREPROD_HOST=preprod.example.org
# …

If the variables are not defined, an error is raised: Erreur : PROD_HOST manquant…. 

ddev db-prod-dump: dumping production, on the server

The command connects to the server over SSH and runs a drush sql-dump --gzip there, into a timestamped file in PROD_DB_PATH:

$ ddev db-prod-dump
Dump de la base de production (mon-serveur.example.org)…
Dump terminé.

Note that the dump stays on the server. This is intentional: it also serves as a one-off backup before a risky operation, without necessarily being downloaded.

ddev db-prod-get: downloading the latest dump

The local counterpart: the command finds the most recent .sql.gz in PROD_DB_PATH on the server and downloads it with scp:

$ ddev db-prod-get
Téléchargement du dump : /var/www/monprojet/dumps/2026-07-28_09-15-42-monprojet.example.org-prod.sql.gz
Dump téléchargé : /home/kevin/projets/monprojet/files/dumps/…

The local destination is resolved in this order: LOCAL_DB_PATH, otherwise DB_DUMP_DIR, otherwise the default: files/dumps. That's no accident: it's exactly the dumps directory of db-import. So the file lands right where db-import will look for "the most recent dump", with no extra configuration.

ddev db-prod-import: the whole package

The command I actually use every day. Its code is two lines long:

ddev db-prod-get
ddev db-import

So, end to end: download of the latest production dump, local database emptied, dump imported, drush deploy, drush cr, drush uli,  to finally get a login link in the terminal.

Note that db-prod-import doesn't trigger a new dump: it takes the latest one already on the server.

ddev ssh-prod

Since the server details are already in the .env, might as well use them: ddev ssh-prod opens an SSH session on the production server of the current project.

What about staging?

Each command has its preprod twin: db-preprod-dump, db-preprod-get, db-preprod-import, ssh-preprod. They are exact copies of the prod variants, where the prefix of the .env variables simply becomes PREPROD_.

Installation and source code

The easiest way is to install the ddev-drupal-tools add-on, which provides these eight commands as well as db-import / db-export and autocompletion:

ddev add-on get kgaut/ddev-drupal-tools

Note: even though the add-on installs its files globally, ddev add-on get must be run from a DDEV project directory (or with --project <name>), because DDEV has no real concept of a global add-on and records the installation in the project used as context, in .ddev/addon-metadata/. To update, run the same command again from the same project; to remove it, ddev add-on remove drupal-tools. The details are in the repository README.

If you want to look at the code of the commands directly: 

• remote dump: db-prod-dump / db-preprod-dump
• downloading the latest dump: db-prod-get / db-preprod-get
• the whole package: db-prod-import / db-preprod-import
• SSH session: ssh-prod / ssh-preprod

For a manual installation, just drop these files into ~/.ddev/commands/host/ and make them executable: DDEV discovers them on its own, nothing to restart. The #ddev-generated marker at the top of each file lets DDEV update and remove them cleanly when they are managed through the add-on.