Hostnames & Routing

Every project is reached by hostname, not by port. This page explains how those hostnames come to be and how to manage them.

How a hostname is formed

By default a project’s hostname is <name>.<base-domain> — for example, project aurora with base domain coding9.test is served at https://aurora.coding9.test.

The routing chain is:

1. dnsmasq answers *.<base-domain> with 127.0.0.1.
2. The macOS resolver at /etc/resolver/<base-domain> forwards the domain to dnsmasq.
3. Traefik (owning ports 80/443) matches the Host() rule in the project’s override and forwards to the right container.
4. The mkcert wildcard certificate makes the connection trusted.

Manage hostnames with host

A project can serve several hostnames. Manage them with mdocker host:

mdocker host

mdocker host ls aurora                       # list current hostnames
mdocker host add aurora admin.aurora.coding9.test
mdocker host rm  aurora admin.aurora.coding9.test

Adding or removing a hostname updates the registry and re-renders the override. It may also regenerate the certificate (to add a new SAN) and restart the router container so Traefik picks up the change. Pass --no-apply to change the registry without re-rendering immediately.

Wildcard hostnames

Wildcard hostnames like *.acme.coding9.test are supported. They are rendered as a Traefik HostRegexp rule that matches exactly one label, and each wildcard must be added to the certificate as its own SAN. Wildcards are matched for routing but a concrete host is used wherever a real URL is needed (for example APP_URL).

Open hostnames in the browser

mdocker open

mdocker open aurora                          # first hostname
mdocker open aurora admin.aurora.coding9.test  # a specific hostname
mdocker open aurora --all                    # every hostname of the project

Related

• CLI: open & host
• Multiple Base Domains
• Concept: The Edge Stack