Setting up DDEV for WordPress Development: Part One

As I’ve posted about previously, I love DDEV. It’s now the daily driver in my development workflow, the main thing every project is set up with. Not just PHP projects, it’s useful for Node/Bun projects too. Having to not even think about setting up a database, a local mail server, cron, is just game-changing, thanks to the amazing DDEV ecosystem, especially add-ons.

Either way, I’ve recently been working on some WordPress plugins and of course, I turned to DDEV for the dev environment. In this post, I’m going to show you a few things that every WP developer that wants to use DDEV must know to make the most of the set-up.

Getting Ready

The DDEV installation process is pretty simple. I’d recommend if you’re a Windows user, using WSL (another absolute game-changer) as the home for your projects and Docker. It’s supported by pretty much all of the major IDEs now as a first-class citizen, so it’s definitely worth using.

The DDEV docs talk you through basic set up of WSL and DDEV so I’ll assume you’ve read and followed that before continuing.

WordPress now has an awesome CLI tool called WP-CLI for working with WordPress from the command line, and the good news is that DDEV bundles it in so it’s available for you straight away.

To get started and create your WordPress site, first you’ll need to create a directory for WordPress. In this example, I’m just going to use wordpress-dev.

Once you’re inside the empty directory, it’s time to set DDEV up!

Now we can start our (still empty) project.

It’ll take a minute or so depending on whether you’ve got the Docker images available locally and on your specs, but it’ll let you know when it’s complete.

We still don’t have WordPress in our project, so there are a couple of options here. We can either download the latest release from WordPress.org and unzip it, or use the fact that our DDEV project has the WP-CLI binary available by default to just download it. The latter is the faster option so let’s do that.

Awesome. You can either now installing it by using ddev launch and following the installation wizard in the browser (tip: the default database has host, name, user and password all set as “db”) or install it entirely using the CLI. We’ll do the latter.

And now you have a local WordPress site, all set up and ready to use with its admin at https://wordpress-dev.ddev.site/wp-admin, ready for us to log in with admin as the user and password as the password!

So, now we’re all set up, let’s cover what DDEV adds to make WP dev a breeze.

Mail Testing & Mailpit

One of the awesome things about DDEV is that it includes Mailpit by default. Mailpit is a really cool piece of software that acts as a local SMTP server, allowing you to easily test email sending without needing to route everything through a real mail provider.

For other projects, you just plug your favourite SMTP or email library into the DDEV defaults:

• Server/Hostname: localhost
• Port: 1025
• Username/Password: [blank]

And you’re away. When an email is sent through this server, it becomes instantly available to see inside Mailpit.

To open Mailpit and view any emails, simply run the command inside your project:

This opens Mailpit in your default browser, ready to go. So how does this work with WordPress?

You can hook WordPress’ mail system into SMTP using a plug-in, but I found out that it’s not necessary at all. WordPress uses sendmail by default, and DDEV/Mailpit intercept this so right off the bat, any email sent from WordPress shows up inside Mailpit.

This is particularly useful when you’re creating a plugin that sends emails, as you can easily test them without needing to enter your real email provider’s credentials.

Database Administration

There can be times when you’re working on a plugin that creates its own database tables and records, and it can be difficult at times to debug using the WordPress admin alone. DDEV allows you to install a variety of add-ons and the catalog is ever-growing.

I like to use Adminer as my general GUI for working with databases and it works straight out of the box with DDEV once you’ve installed it.

To get started, simply plug the add-on into your project:

Restart the project using:

And it’s ready to use. Simply run:

And similar to Mailpit, it opens straight away in your browser, connected to the default DDEV database, ready for you to tinker away.

Bind Mounts and External Folders

When creating a WordPress plugin or theme, it’s tempting to start working straight away in the wp-content/plugins or themes directory. It’s fast, everything loads straight away in DDEV, you can see instant changes. Until it stops being fun.

It’s easy to have an array of plugins and themes that you’re working on, all showing up in the wp-content directory, all with their own git repositories, build scripts, etc. that DDEV really doesn’t need.

I, like you, started that way. I wanted to package the whole directory without packaging my build script, so did it from one directory higher, in the plugins directory, and it became a mess. I started looking for a solution, and then realised that DDEV, using Docker under the hood, already has a beautiful solution to this very problem – mounts.

Rather than having your project’s theme files inside the WordPress installation directly, we can keep all of our plugins and themes separate, and use Docker’s mounting features.

The idea is simple, we have our dev blog’s WordPress files under /home/ryan/dev/wordpress-dev – this is the directory where WordPress lives, and its plugins directory is at /home/ryan/dev/wordpress-dev/wp-content/plugins.

We also have our plugin directory. This can be in a completely different location, say, at /home/ryan/dev/our-awesome-plugin.

Now, to link the two together we create a new file inside /home/ryan/dev/wordpress-dev/.ddev and call it docker-compose.override.yaml with the following contents:

services:
  web:
    volumes:
      - /home/ryan/dev/our-awesome-plugin:/var/www/html/wp-content/plugins/our-awesome-plugin

And then we restart the DDEV project with:

And now, our new plugin is in exactly the place it needs to be, but we can edit it completely separately from the ~/dev/our-awesome-plugin directory. All of the changes made in this directory are instantly available to WordPress because this directory is essentially mounted inside the WordPress installation plugin’s directory.

This was the biggest game-changer for me. It uses Docker’s built-in features to allow us to pull in plugins from other parts of the filesystem which can really help with code organisation. Nice.

Conclusion

DDEV has quietly become one of those tools I don’t really think about anymore – and honestly, that’s kind of the point. Once it’s set up, it just gets out of the way and lets you focus on actually building things instead of fighting your environment.

For WordPress development especially, it removes a lot of the usual friction: databases, email testing, local servers, and plugin isolation all just work without much ceremony.

What I’ve covered here is really just the starting point – enough to get a project up and running and comfortable enough to start building plugins or themes properly.

In a follow-up post, I’ll dig into some of the more practical day-to-day workflows like working with real databases, debugging with Xdebug, and handling cron in a way that actually matches production behaviour.

For now, good luck and happy developing!