Magic behind DDEV & Lando Routing

Today we'll discuss how the these docker based local environments for development like ddev or lando works.
These tools makes everything magical, and the end user just needs to setup a project run commands like ddev start or lando start and all the docker containers will spins up and the user will be able to visit the web page by with the url .ddev.site or in case of lando .lndo.site.

😉 Spoiler Alert all these tools uses cheeky DNS mapping & reverse proxy like tool traefik.

This guide is perfect for beginners or intermediate developers looking to understand how containerized local dev environments like DDEV use Traefik for networking.

If you're new to tools like DDEV or Lando and don't know what they are used for, they are local development environment based on Docker. You can easily setup a development environment for Drupal or Wordpress or MERN/MEAN and many other frameworks. As they use Docker containers for installing dependencies local development becomes very easy.

Let's take an example with DDEV.
In DDEV you can setup a Wordpress Project simply with the following commands, considering DDEV is already setup on your system.

cd <project-directory-name>
ddev config --project-type=wordpress --docroot=.
ddev wp core download
ddev wp core install --url=https://<project-directory-name>.ddev.site --title="<Site Name>"
--admin_user=admin --admin_password=admin --admin_email=[e-mail]

Now after setting up the project, ddev start will spin up all the containers & run your site in the URL https://<project-directory-name>.ddev.site

Today we'll discuss how this internal routing of https://<project-directory-name>.ddev.site works to your local site.

This is mainly done in two phases

1. DNS Mapping

DNS or Domain Name Server mapping is done to assign an IP address to a specific domain. When you type https://google.com on the browser. The browser doesn't know what server to request & how it can serve the html. The domain https://google.com is being resolved to a IP & then the client or the browser requests the server. This is called DNS Mapping.
Now in order the browser to know that accessing a site with the URL https://<project-directory-name>.ddev.site needs to request it's own machine where the project belongs. The URL needs to be resolve to 127.0.0.1.
This custom DNS mapping is created for DDEV & Lando.
You can check this by resolving the URLs *.ddev.site or *.lndo.site

In this simple way, ddev or lando creates custom URL for local Development.

1. Proxy Server — Enter Traefik

Now that DNS mapping ensures *.ddev.site (or *.lndo.site) resolves to your local machine (127.0.0.1), the next question is: how does your browser’s request for
https://<project-directory-name>.ddev.site actually reach the correct container running your project?

This is where Traefik steps in.

Traefik is a modern reverse proxy and load balancer designed for containerized environments. It automatically discovers running containers and routes incoming HTTP/HTTPS requests to the right service — all without you lifting a finger.

In DDEV (and similarly in Lando), Traefik runs as a global container that listens on ports 80 (HTTP) and 443 (HTTPS). When you run ddev start, your project containers register themselves with Traefik through Docker labels. These labels contain routing information — such as the domain name (.ddev.site) and the internal container port (like 80 or 8080).

Here’s what happens under the hood when you visit https://<project-directory-name>.ddev.site:

1. Browser Request: Your browser sends a request to https://<project-directory-name>.ddev.site.
2. DNS Resolution: The *.ddev.site wildcard DNS resolves to 127.0.0.1, pointing to your local machine.
3. Traefik Intercepts: The request hits Traefik’s HTTPS listener (port 443). Traefik inspects the hostname .ddev.site and checks its internal routing table.
4. Container Discovery: Traefik, using Docker’s API, has already discovered that a container labeled Host(.ddev.site) exists. It knows this container’s internal IP and port.
5. Secure Routing: Traefik forwards the request securely to the correct container. It also handles SSL/TLS termination — meaning your site works seamlessly over HTTPS using Traefik’s automatically generated certificates.
6. Response: The container serves your app, and Traefik relays the response back to the browser.

So while it looks like you’re visiting a remote, hosted website at https://<project-directory-name>.ddev.site, you’re actually interacting with your own machine. Traefik quietly proxies everything behind the scenes — no hosts file edits, no manual configuration.

Diving into the details of how these local development environments handled routing was a great learning for me. In a future article we can try and implement similar kind of model with simple docker & docker compose and run our local sites with custom URL.

Please leave a comment below, if you've like this article or have any kind of queries or suggestions for me.