DDEV: Docker-based local PHP and Node.js environments without learning Docker

The setup problem DDEV removes for PHP and Node.js teams

A PHP project needs a web server, a database, a PHP version, and often Node.js for asset builds. Doing that by hand means writing Docker Compose files, wiring hostnames, generating TLS certificates, and keeping all of it in sync across a team. DDEV takes that work and turns it into one configuration file per project, which the README describes as "One setup per project: keep it in Git and share the same environment with your whole team." The target reader is a PHP developer on macOS, Windows 11, WSL2, Linux, or GitHub Codespaces who wants containers but does not want to author Compose files. The README states the pitch plainly: "Get the power of Docker without needing to know Docker." That is a positioning statement, not a technical one, and it holds only as long as your stack matches what DDEV already knows how to configure.

How DDEV drives Docker Compose from a per-project config

DDEV is a Go binary, not a container you run first. The repository's go.mod lists github.com/docker/cli, github.com/docker/compose/v5, github.com/compose-spec/compose-go/v2, github.com/moby/moby/client, and github.com/spf13/cobra, which tells you the shape of the thing: a Cobra command tree that talks to the Docker API and Compose libraries directly, rather than shelling out to a bundled Compose binary. The containers themselves live in the containers/ directory of the repository, and the cmd/ and pkg/ directories hold the CLI and its logic. Because the configuration is per project and the README says to keep it in Git, the practical data flow is: you commit the project config, a teammate clones the repository, runs ddev start, and DDEV builds the same services on their machine. The stack is selectable per project rather than global. The README lists PHP 5.6 through 8.5, Nginx or Apache as the webserver_type, and MariaDB, MySQL or PostgreSQL as database types, plus "any version of Node.js you need." The README also states that trusted HTTPS, Xdebug, database snapshots, and hosting integrations with Upsun (formerly Platform.sh), Pantheon, and Acquia are included out of the box. Those integrations are the part that matters for teams migrating databases down from a host, since pulling a database is a routine chore that DDEV tries to make a single command.

Installing DDEV and starting your first project

The README does not print install commands inline. It points at the Get Started guide at ddev.com/get-started/, which asks for your operating system and returns the install commands and a first project on one page, and at docs.ddev.com/en/stable/users/install/ for the full instructions. The order matters: the README says to install a Docker provider first, then DDEV. So the first step is not a DDEV command at all. Once both are in place, the README says to pick a quickstart guide for your CMS or framework and then run ddev start. The commands below are the ones the README lists under Everyday commands.

ddev start

This creates and starts the project's containers. The README describes it as the way to "run or pause a project's containers" alongside ddev stop. On a first run you should expect image pulls, which take longer than subsequent starts.

ddev list

The README describes ddev list as the way to "see every project on the machine." Use it to confirm the project registered and to read its status before you go further. For the full command reference the README points you at running ddev on its own.

ddev import-db

The README lists ddev import-db for loading a database dump and notes the companion ddev import-files for user-uploaded files such as Drupal sites/default/files and WordPress wp-content/uploads. Run ddev import-db --help on your installed version before scripting it, since the README does not print any flags for it.

ddev snapshot

This saves database state, per the README's description of ddev snapshot as "save and restore database state." It is the cheap undo you want before running a migration or a destructive import.

ddev exec

Runs a command inside the web container. The README pairs it with ddev ssh, which opens a shell in the same container, and with ddev logs for container logs. If you need to hand a URL to a colleague or a client, ddev share is the README's answer: it provides "a temporary public URL for your local site."

Where DDEV stops being the right tool

DDEV assumes a web application with a database behind it, and the topics list on the repository confirms the audience: Drupal, WordPress, Laravel, TYPO3, Magento, Craft CMS, Backdrop, Moodle, plus Node.js. If your service is a Go or Rust daemon, a message consumer, or a data pipeline with no HTTP front end and no database, the per-project model buys you nothing and the Docker provider requirement is pure overhead. The second constraint is that DDEV does not remove Docker, it hides it. The README is explicit that you install a Docker provider separately, and the system requirements page is where supported providers are enumerated. When a container fails to start, you are debugging Docker, and the abstraction does not protect you there. Third, the README does not document rollback of a DDEV version upgrade, nor does it make a compatibility promise about which DDEV release supports which Docker provider version. If your team pins tool versions for reproducibility, that gap is worth knowing about before you standardize. Finally, DDEV is maintained by the nonprofit DDEV Foundation and funded by sponsors and community contributions, which the README states directly. That is a governance fact, not a defect, but it means release cadence depends on sponsorship rather than a commercial roadmap.

DDEV against hand-written Docker Compose and Lando

The honest alternative for most DDEV users is a docker-compose.yml you write and maintain yourself. The difference is where the configuration lives and who owns it. With hand-written Compose you control every service definition, every volume mount, and every network, and you can express topologies DDEV's per-project model does not anticipate. You also own hostname resolution, TLS certificates, database import tooling, and the onboarding document, forever. DDEV's bet is that those four things are the same for nearly every PHP project, so they should be generated rather than written. Lando is the closer comparison, since it targets the same CMS development audience with a per-project config file. The architectural difference visible here is that DDEV is a single Go binary using the Docker and Compose Go libraries directly, while Lando's own implementation is not something this material describes, so I will not characterize it. What the DDEV repository does show is the extension path: add-ons at addons.ddev.com for extra services and integrations, and custom commands that the README says are "ordinary shell scripts." If your requirement is a service nobody has written an add-on for, you are back to writing container definitions, just inside DDEV's structure instead of your own.

Licence, releases and the cost of staying current

DDEV is Apache-2.0, and the LICENSE file sits at the repository root. Apache-2.0 is permissive and includes an express patent grant, which matters if you redistribute the binary inside a company image. It does not require you to publish modifications. Note that the repository vendors its Go dependencies in a vendor/ directory, so a fork carries third-party code under its own licences; if you ship a modified DDEV, the NOTICE and licence obligations of those vendored modules apply alongside Apache-2.0. Nothing here is legal advice, and a redistribution review should read LICENSE and the vendored module licences rather than this paragraph. On upgrade cost, the release history shows a steady cadence with v1.25.4 on 2026-09-02, v1.25.3 on 2026-07-06, and v1.25.2 on 2026-04-22, and the last push to the repository was on 2026-09-23. The maintenance burden for a user is mostly the Docker provider, not DDEV itself: the README requires a separate Docker provider install, so provider upgrades and DDEV upgrades are two moving parts. The README does not document a rollback procedure for a DDEV version, so if you standardize a version across a team, keep the previous installer around yourself.

Editorial conclusion

Adopt DDEV if your team runs PHP CMS or framework projects (Drupal, WordPress, Laravel, TYPO3, Magento, Craft CMS, Backdrop, Moodle) and wants the environment committed to Git, or if you need PHP 5.6 through 8.5, Nginx or Apache, and MariaDB, MySQL or PostgreSQL selectable per project. Do not adopt it if your project is not PHP or Node.js, or if you already run a Kubernetes-based development platform that your team will not replace. Before committing, verify on your own machine that a Docker provider is installed, that ddev start completes for one real project, and that ddev snapshot followed by ddev snapshot restore returns your database to the expected state.

Frequently asked questions

Official sources

1. ddev/ddev on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases