Deployed should have an address.

A container definition can describe its web address while the DNS record still has to be created elsewhere. That second task is easy to forget, and the resulting failure looks like an application problem even when the application is healthy.

DNS is only one part of publishing. A record may exist while a tunnel route is missing, the proxy is targeting the wrong port or the sign-in layer is absent. Combining those states into one green indicator hides the work still required.

For self-hosted operators using Docker, Traefik and Cloudflare, and for platforms that want application deployment and DNS to follow the same configuration.

We maintain CF Companion as the DNS automation component in our container ecosystem. It watches Docker events and reads hostnames from Traefik labels to create the corresponding Cloudflare records. The catalog definition supplies its domain, zone and token configuration.

That keeps the desired hostname close to the service definition. We can use the same declared application address to drive routing and the DNS step instead of asking an operator to transcribe it into another dashboard.

A routed container declares its hostname. CF Companion observes Docker, reads that routing label and uses the configured Cloudflare credentials to create the DNS record. The reverse proxy and any tunnel still need their own valid routes to deliver the request to the app.

Our October 2026 operating account shows why those boundaries matter. A running companion had lost its event connection and stopped creating records. Restoring it created the missing record, but a tunnel rule and an application-port correction were still needed before the page worked.

The engineering challenge is keeping the integration connected and checking the outcome outside its own process. A running container is not evidence that DNS automation is listening. Our verification of the wider publishing path ends at the application's actual address, where the person using it starts.