It's a neat trick, but it comes with some caveats. For instance, `localhost` often resolves to both 127.0.0.1 and ::1, but `.localhost` is described in RFC2606 as "traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use". In other words, your server may be binding to ::1 but your browser may be resolving 127.0.0.1. I'm sure later RFCs rectify the lack of IPv6 addressing, but I wouldn't assume everyone has updated to support those.
Another neat trick to combine with .localhost is using 127.0.0.0/8. There's nothing preventing you from binding server/containers to 127.0.0.2, 127.1.2.3, or 127.254.254.1. Quite useful if you want to run multiple different web servers together.
Of course, in the early internet, the difference between a TLD and a host name weren't quite as clear as they are right now.
I cannot ping xyz.localhost because it doesn't resolve it.
EDIT: on linux and don't use launchd, so I'd still the port number
Self sign a certificate and add it to your trusted certificate list.
Or - use https://pinggy.io
They also show having the webserver to the TLS, that might be helpful.
Forgot to add .local I see
What it does is it has a private network for the containers and itself (all containers get their own unique IP, so there's no port mapping needed).
http://orb.local simply lists all running containers.
The host-names are automatically derived from the containername / directoryname / compose project, but you can add other hostnames as well by adding docker labels.
It works really well.
Would be good to have the config all somewhere in my user's dir too.
Per user subdomains for their apps on localhost.
It works really well and means no setup on our developers machines
Then we just have an entry for local.example.com in our vhosts and bam everything works as expected. No need to mess with /etc/hosts
localhost.localdomain