How DDEV Works¶
The easiest way to think about how DDEV works is to think of it as a set of little networked computers (docker containers). You can think of them as being in a different network world than your workstation computer, but reachable from there.
When you install or upgrade DDEV you're mostly installing a single binary, named
ddev. When you use it, it downloads the Docker images it needs, and then starts them based on your project's needs.
ddev-webservercontainer (one per project) runs
php-fpmfor a single site, so it does all the basic work of a PHP-interpreting webserver.
ddev-dbservercontainer (one per project) handles MariaDB/MySQL/Postgresql database management. It can be reached from the webserver by the hostname
dbor with the more explicit name
- The optional
dbacontainer runs PhpMyAdmin for projects with MySQL or MariaDB.
- Additional add-on services may be there for a given project, for example
Although it's not common usage, different projects can communicate with each other as described in the FAQ
Now for the two oddball containers, which are global (there is only one of each).
ddev-routercontainer is a "reverse proxy". It takes incoming HTTP/S requests and looks up the hostname in the incoming URL and routes it to the correct project's
ddev-webserver. Depending on the project's configuration with
additional_fqdnsit can route many different URLs to a single project's
ddev-webserver. If like most people you use the named URLs (like
https://something.ddev.site) then your request goes through the router. When you use the
127.0.0.1URLs, the requests go directly to the
ddev-ssh-agentcontainer runs an
ssh-agentinside the docker network so that after you do a
ddev auth sshall the different projects can use your ssh keys for outgoing requests (like private composer access or scp from a remote host).
Here's a basic diagram of how it works inside the docker network: