Troubleshooting Pressable DDEV Syncs

Last modified: July 31, 2026

Ask Your Favorite AI

Copy the link to a markdown format of this article for ChatGPT, Claude, Gemini, or your favorite AI.

For WordPress developers using the ddev-pressable add-on

Errors from a DDEV sync usually come from one of three places: the local certificate setup, SSH access to your Pressable site, or code that the sync deliberately doesn’t move. Find your symptom below. If you haven’t set the add-on up yet, start with Sync A Pressable Site To Your Local DDEV Environment.

mkcert CA files are not readable On ddev start

The full warning looks like this:

mkcert CA files are not readable from `mkcert -CAROOT` ...
run `mkcert -install` to trust HTTPS

mkcert -install was run with sudo, so the certificate authority was written into root’s home directory. DDEV runs as you and can’t read it.

Re-run the command as yourself, without sudo, then restart:

bash

mkcert -install
ddev restart

It will still ask for your password once. That prompt is for the single step that adds the CA to the system trust store, which is expected.

ddev auth ssh Seems To Hang

Your SSH key has a passphrase and the command is waiting for you to type it. There’s no visible prompt in some terminals, so it looks frozen.

Run it in an interactive terminal rather than a script or a task runner. Once the key is loaded it stays in DDEV’s agent until you run ddev poweroff, so you only do this once per session.

Permission denied (publickey,password), Even After “Server Accepts Key”

A verbose SSH attempt can print Server accepts key and then refuse the connection anyway. That line is not confirmation that your key is authorized: the gateway acknowledges the key during the handshake and checks it against its own records afterward.

Two things to verify in the MyPressable control panel, under your site’s SFTP/SSH section:

  • Your public key is attached to this exact site. Keys are per site, so a key added to a different site won’t work here.
  • The SFTP/SSH username you set in PRESSABLE_SSH_USER belongs to that same site. Copying an SFTP/SSH username from another site is an easy mistake.

Also confirm SSH access is enabled for that user, while it is automatically available to the site owner, a collaborator requires a specific permission. Then test again with the read-only check:

ddev exec ssh -o BatchMode=yes -o StrictHostKeyChecking=accept-new \
  "$PRESSABLE_SSH_USER@ssh.pressable.com" "wp option get siteurl"

If that prints your production URL, the connection is fine and the problem is elsewhere.

Ports 80 Or 443 Reported Busy On Start

Something else on your machine is already using them. DDEV picks alternate ports and prints the real URL, something like https://my-site.ddev.site:33001. Syncing is unaffected, so you can ignore this.

The Pull Succeeded But The Site Doesn’t Render

The add-on moves the database and uploads, never your theme or plugin code. A freshly pulled site has content but nothing to render it with.

Bring your code down from git, or copy it off the site with rsync. Step 7 of the Pressable ↔ DDEV setup guide covers both. Then confirm what landed:

ddev wp theme list
ddev wp plugin list

The full error ends with cannot delete non-empty directory. Some plugins in wp-content/plugins/ are platform-managed symlinks rather than real directories, Jetpack and Akismet among them. When rsync tries to write a symlink over a local directory that already has files in it, it stops.

Add -L so rsync follows the symlink and copies the real files instead of the link:

rsync -azL -e ssh \
  <your-site-ssh-user>@ssh.pressable.com:htdocs/wp-content/plugins/ \
  wp-content/plugins/

The collision most people hit is Akismet, because ddev wp core download unpacks WordPress core’s own bundled copy before rsync ever runs. To see which plugins are symlinked on your site:

ssh <your-site-ssh-user>@ssh.pressable.com "ls -la htdocs/wp-content/plugins/ | grep '^l'"

Production URLs Still Appear In Content

The post-pull hook rewrites siteurl and home, but some plugins store absolute URLs inside serialized or JSON option values, which a simple rewrite misses.

Find them first:

ddev wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%YOUR-PRODUCTION-DOMAIN%'"

Then finish the rewrite in a way that’s safe for serialized data. Run it twice, because JSON-encoded options store escaped slashes:

ddev wp search-replace 'https://YOUR-PRODUCTION-DOMAIN' 'https://my-site.ddev.site' \
  --all-tables-with-prefix --skip-columns=guid

ddev wp search-replace 'https:\/\/YOUR-PRODUCTION-DOMAIN' 'https:\/\/my-site.ddev.site' \
  --all-tables-with-prefix --skip-columns=guid

Note that DDEV defines WP_HOME and WP_SITEURL at runtime, so the front end can show the correct local URL while stale values sit in the database. Query the stored value directly rather than trusting what the site displays:

ddev wp db query "SELECT option_value FROM wp_options WHERE option_name='siteurl'"

The Local Site Can’t Reach A Cache Service

Errors mentioning object caching or Memcached mean a wp-content root drop-in was copied down. object-cache.php and advanced-cache.php point at caching services that exist on Pressable but not inside DDEV.

Delete the local copies:

rm wp-content/object-cache.php
rm wp-content/advanced-cache.php

Copy only themes/ and plugins/ in future, and leave the wp-content root alone.

A Push Went To The Wrong Site

ddev push pressable overwrites the remote database with your local one. There is no undo on the add-on side. Anything created on the target since your local copy was pulled is gone: orders, comments, form entries, new posts.

If this happened to a live site, stop working on it and restore from a backup. Pressable takes automated backups, and you can restore one yourself from the site’s Backups section in the MyPressable control panel. Pick the most recent backup taken before the push.

Whatever was created between that backup and the push is not recoverable. For this reason you may want to manually backup your Pressable site before a push.

To avoid it, check which site PRESSABLE_SSH_USER points at before every push, read the confirmation prompt rather than clicking through it, and never pass -y.

Still Stuck?

Pressable support can help with SSH access on your site: confirming your public key is attached, checking SSH is switched on, and finding your site’s SSH username. Everything past that point runs on your own machine.

For DDEV itself, see the DDEV documentation. For the add-on, including bug reports, use github.com/pressable/ddev-pressable.