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:
- Documented the existing setup (PHP version, Apache vhosts, env vars, Xdebug config)
- Created a
.ddev/config.yamltranslating every piece of that config - Tested against the existing codebase end-to-end
- Wrote a setup guide (a single
READMEsection: install WSL2, install Docker Desktop, install DDEV, runddev start) - 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
- 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