I haven't done it for a while (I've mostly just used 127.*), but I found the best one to use for dev purposes was the IETF-reserved `.test` TLD [0]. The main benefit at the time I was messing with this (10ish years ago now) was that all the browsers I needed to test on would actually attempt to resolve `.test`. If I remember correctly, firefox seemed to have issues with `localhost` being anything other than 127.0.0.1 (and would simply go to that address ignoring whatever was in /etc/hosts or DNS, again IIRC). It's been a while, though, so that behavior might have changed.

[0] https://datatracker.ietf.org/doc/rfc2606/

Recently I started to work on a very simple tool to do this with a single command: it'll start all your projects in a given directory and expose them via HTTPS on https://[project].localhost

No daemons, and the only piece of configuration is adding a file to /etc/resolvers: https://github.com/djanowski/hostel

I've been using it for myself so it's lacking documentation and features. For example, it expects to run each project using `npm run dev`, but I want to add Procfile support.

Hopefully other people find it useful. Contributions very much welcome!

I do something similar with Caddy but add dns-sd to broadcast on mDNS so i can just hit myapp.local from anywhere on my network and don't have to do anything with hosts and it just works. Been on my todo list to wrap this into a tiny mac menubar app.

The comments here all suggesting different arcane and complicated stacks of different devops solutions and certificates and configurations and services has me somewhat despairing that such a COMMON usecase is still so annoyingly obtuse.

I pondered the question of local-only domains since long ago, and in consultation with Chris Siebenmann, I determined that the most courteous way was actually to subdomain from my ISP.

That’s right: I invented a fictitious subdomain under one my ISP controlled and I never registered it or deployed public DNS for it. It worked great, for my dumb local purposes.

Example:

  aten.mysub.isp.net.
  porta.mysub.isp.net.
  smartphone.mysub.isp.net.

Thus it was easy to remember, easy to add new entries, and was guaranteed to stay out of the way from any future deployments, as long as my ISP never chose to also use the unique subdomain tag I invented...

People used localtest.me back in the days :)

https://weblogs.asp.net/owscott/introducing-testing-domain-l...

I just use https://myapp.localhost:2948 so I don't need to remember the port number. The browser autocomplete handles that, so I don't really see the need for server-side help.

BTW, there seems to be some confusion about *.localhost. It's been defined to mean localhost since at least 2013: https://datatracker.ietf.org/doc/html/rfc6761#section-6.3

It's easy with Caddy to setup it in a way that you can have your api and SPA app in under the same domain in order to avoid CORS-issues.

myapp.localhost { tls internal

    # Serve /api from localhost:3000 (your API)
    @api path /api/*
    handle @api {
        # Remove the leading "/api" portion of the path
        uri strip_prefix /api
        reverse_proxy 127.0.0.1:3000
    }

    # Fallback: proxy everything else to Vite's dev server on 5173
    handle {
        reverse_proxy 127.0.0.1:5173
    }

}

You're welcome.

Thanks for sharing!

This is cool, but it only seems to work on the host that has the /etc/hosts loopback redirect to *.localhost. I run my app on a home server and access it from multiple PCs on the LAN. I have several apps, each associated with a different port number. Right now, I rely on a start page (https://github.com/dh1011/start-ichi) to keep track of all those ports. I’m wondering if there’s an easy way to resolve custom domains to each of those apps?