Skip to content
· 1 min read·
PHPDDEVDockerDevOpsDeveloper Experience

From XAMPP to DDEV: Modernizing PHP Developer Environments

How switching from a manual Windows/XAMPP setup to WSL + DDEV + Docker cut onboarding from a day or two to a couple of hours - and what I learned doing it for the team.

Setting up a PHP development environment used to be a rite of passage - and not the fun kind.

When I joined the team, the local dev setup had grown organically over the years - XAMPP on Windows, manual SSL certificates, environment variables scattered across .htaccess files. Six developers, all with subtly different configurations.

The problem

The worst part wasn't the setup itself - it was onboarding. Getting a new developer productive took a day or two of hand-holding: installing the right PHP version, configuring Apache virtual hosts, mapping drive letters, fighting with Xdebug config. And the move to WSL added a step before any of that - not everyone was comfortable setting up the Linux side and installing tooling inside it in the first place.

Every developer had a slightly different environment, which meant bugs that were genuinely environment-specific.

The solution: WSL + DDEV + Docker

DDEV is an open-source local development environment tool built on Docker. It gives every project a reproducible, containerised environment defined entirely in .ddev/config.yaml - committed to the repo.

Combined with WSL2 (Windows Subsystem for Linux), we got:

  • Consistent environments - the same Docker image on every machine
  • Per-project PHP versions - no more global PHP installation conflicts
  • Built-in Xdebug - one command to enable/disable
  • Mailpit - local email catching out of the box

The migration

The migration itself took about a week:

  1. Documented the existing setup (PHP version, Apache vhosts, env vars, Xdebug config)
  2. Created a .ddev/config.yaml translating every piece of that config
  3. Tested against the existing codebase end-to-end
  4. Wrote a setup guide (a single README section: install WSL2, install Docker Desktop, install DDEV, run ddev start)
  5. Automated the WSL side with an Ansible playbook (Griffin) so provisioning the Linux tooling wasn't a manual, error-prone step either - between that and DDEV's containers, a fresh machine goes from nothing to running in a couple of hours, most of it just Docker pulling images
  6. Ran a 2-hour workshop with the team

Results

Onboarding dropped from roughly a day or two of manual setup to a couple of hours - most of that now just Docker pulling images. The environment is fully reproducible: any developer can check out the repo and have a working local setup with ddev start, no more "works on my machine" from mismatched local tooling.

I also contributed a bug fix back to the DDEV project (PR #6809) while doing the migration - a small way to give back to the tool that saved us hours.

Takeaways

  • The upfront investment in a reproducible environment pays off immediately at hiring time
  • DDEV's .ddev/ directory in version control is the key - no more "ask the guy who set it up originally"
  • Running a short workshop beats documentation alone; people need to do the setup once with someone watching

Newsletter

I write about software architecture, PHP, Vue, TypeScript, and developer experience. No spam, unsubscribe anytime.

Copyright © 2026. All rights reserved.