You might check out .internal instead which was recently approved [1] for local use.

[1]: https://en.wikipedia.org/wiki/.internal

Note: browsers also give you a Secure Context for .localhost domains.

https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

So you don't need self signed certs for HTTPS on local if you want to, for example, have a backend API and a frontend SPA running at the same time talking to eachother on your machine (authentication for example requires a secure context if doing OAuth2).

This nginx local dev config snippet is one-and-done:

  # Proxy to a backend server based on the hostname.
  if (-d vhosts/$host) {
    proxy_pass http://unix:vhosts/$host/server.sock;
    break;
  }

Your local dev servers must listen on a unix domain socket, and you must drop a symlink to them at eg /var/lib/nginx/vhosts/inclouds.localhost/server.sock.

Not a single command, and you still have to add hostname resolution. But you don't have to programmatically edit config files or restart the proxy to stand up a new dev server!

Chrome and i think Firefox resolve all <name>.localhost domains to localhost per default, so you don't have to add them to the hosts file. I setup a docker proxy on port 80 that resolves all requests from <containername>.localhost to the first exposed port of that container (in order of appearing in the docker compose file) automatically which makes everything smooth without manual steps for docker compose based setups.

If you’re interested in doing local web development with “real” domain names, valid ssl certs, etc, you may enjoy my project Localias. It’s built on top of Caddy and has a nice CLI and config file format that you can commit to your team’s shared repo. It also has some nice features like making .local domain aliases available to any other device on your network, so you can more easily do mobile device testing on a real phone. It also syncs your /etc/hosts so you never need to edit it manually.

Check it out and let me know what you think! (Free, MIT-licensed, single-binary install)

Basically, it wraps up the instructions in this blogpost and makes everything easy for you and your team.

https://github.com/peterldowns/localias

Any subdomain of .localhost works out-of-the-box on Linux, OpenBSD and plenty of other platforms.

Of note, it doesn't work on macOS. I recall having delivered a coding assignment for a job interview long ago, and the reviewer said it didn't work for them, although the code all seemed correct to them.

It turned out on macOS, you need to explicitly add any subdomains of .localhost to /etc/hosts.

I'm still surprised by this; I always thought that localhost was a highly standard thing covered in the RFC long long ago… apparently it isn't, and macOS still doesn't handle this TLD.

Against much well-informed advice, I use a vanity domain for my internal network at home. Through a combination Smallstep CA, CoreDNS, and Traefik, any services I host in my Docker Swarm cluster automatically are immediately issued a signed SSL certificate, load-balanced, and resolvable. Traefik also allows me to configure authentication for any services that I may not wish to expose without such.

That said, I do recommend the use of the internal. zone for any such setup, as others have commented. This article provides some good reasons why (at least for .local) you should aim to use a standards-compliant internal zone: https://community.veeam.com/blogs-and-podcasts-57/why-using-...

OP: If you're already using Caddy, why not just use a purchased domain (you can get some for a few dollars) with a DNS-01 challenge? This way you don't need to add self-signed certificates to your trust store and browsers/devices don't complain. You'll still keep your services private to your internal network, and Caddy will automatically keep all managed certificates renewed so there's no manual intervention once everything is set up.

BTW you can actually give every locally-hosted app a separate IP address if you want. The entire 127.0.0/24 is yours, so you can resolve 127.0.0.2, 127.0.0.3, etc as separate "hosts" in /etc/hosts or in your dnsmasq config.

Yes, this also works under macOS, but I remember there used to be a need to explicitly add these addresses to the loopback interface. Under Linux and (IIRC) Windows these work out of the box.

On my Linux machine with systemd-resolved, this even works out the box:

  $ resolvectl query foo.localhost
  foo.localhost: 127.0.0.1                       -- link: lo
                 ::1                             -- link: lo

Another benefit is being able to block CSRF using the reverse proxy.

I use .localhost for all my projects. Just one annoying note: Safari doesn't recognize the TLD localhost so it will try to perform a search. Adding a slash at the end will fix this; ie example.localhost/

When Apple's MobileMe came out I snagged the localhost@me.com email address, thinking how clever I was. But because filtering tools weren't as good back then I was never able to use it because of the truly massive amount of spam and test emails I'd get.

In my case I just setup a subdomain 'local.<domain>' to my personal domain and had Let's Encrypt create valid certificates for it via Traefik.

Each service is then exposed via '<service>.local.<domain>'.

This has been working flawlessly for me for some time.

Avoid using `.local`. In my experience Chrome does not like it with HTTPS. It takes much much longer to resolve. I found a Chrome bug relating to this but do not have it handy to share. `.localhost` makes more sense for local development anyways.

I went a different way for my internal network, I use tv.it for my server and rt.it for the router. All two characters .it domains are non registrable so you risk no clash, the only existing one is q8.it.

I have a more in depth write up here: https://www.silvanocerza.com/posts/my-home-network-setup/

My preference for local TLDs is just .x because it takes less time to enter on mobile devices. An example is www.x or video.x.

Yes, it does require a cert for TLS and that cert will not be trusted by default. I have found that with OpenSSL and a proper script you can spin up a cert chain on the fly and you can make these certs trusted in both Windows and Linux with an additional script. A script cannot make for trusted certs in Safari on OSX though.

I figured all this out in a prior personal app. In my current web server app I just don’t bother with trust. I create the certs and just let the browser display its page about high risk with the accept the consequences button. It’s a one time choice.

I too made a version of this (just a small Go DNS resolver + port forwarding proxy) that lets you do a similar thing: https://gitlab.com/amedeedabo/zoxy

I used the .z domain bc it's quick to type and it looks "unusual" on purpose. The dream was to set up a web UI so you wouldn't need to configure it in the terminal and could see which apps are up and running.

Then I stopped working the job where I had to remember 4 different port numbers for local dev and stopped needing it lol.

Ironically, for once it's easier to set this kind of thing up on MacOS than on Linux, bc configuring a local DNS resolver on linux (cf this taiscale blog post "The Sisyphean Task Of DNS Client Config on Linux" https://tailscale.com/blog/sisyphean-dns-client-linux). Whereas on Mac it's a couple commands.

I think Tailscale should just add this to their product, they already do all the complicated DNS setup with their Magic DNS, they could sprinkle in port forwarding and be done. It'd be a real treat.

This is an ok way of doing things but you don't need Caddy server (or similar), you can put all the http servers on different localhost ip addresses eg 127.0.0.1, 127.0.0.2, etc. They can all use port 80 but on different ip addresses.

A possible disadvantage is that specifying a single ip to listen on means the http server won't listen on your LAN ip address, which you might want.

You might not need the hosts file hack if your DNS supports *.localhost as a wildcard. I think most GNU/Linux distros (in particular the systemd ones) and Mac OS do. You can test it by seeing if `host test.localhost` already resolves to 127.0.0.1 (or ::1).

If you are using other systems then you can set this up fairly easily in your network DNS resolver. If you use dnsmasq (used by pihole) then the following config works:

    address=/localhost/127.0.0.1
    address=/localhost/::1

There are similar configs for unbound or whatever you use.

I have a ready to go docker-compose setup using Traefik here: https://github.com/georgek/traefik-local

Rather than do all this manually each time and worry about port numbers you just add labels to docker containers. No ports, just names (at least for http stuff).

> I then run and configure Caddy to redirect traffic from 127.0.0.1 to the right port for the domain.

That's not redirection per se, a word that's needlessly overloaded to the point of confusion. It's a smart use of a reverse proxy.

It would be nice if you all reserved the word "redirect" for something like HTTP 3xx behavior.

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?

undefined

I think you don't really need the /etc/hosts entry, I use this since google started using .dev domains and switched to using .localhost for everything local.

Never needed the entry

I recently tried to use the dnsmasq method mentioned at the very end but had some issues with fallthrough, as most of my dns traffic went trough my dev setup then first, which I didn't want. In the end I configured a "real" domain and let it point to 127.0.0.1, because I need arbitrary wildcard subdomains.. but I'm still not very happy with it because it feels like an unecessary dependency.

Neat setup! I do something similar on OpenBSD. I have a CSV file that maps IP, MAC address, and hostname for various devices on my LAN. A shell script reads the file and creates a matching hosts file, dhcpd config, and unbound config, then restarts dhcpd and unbound (caching DNS server).

Whenever a host requests a DHCP lease it receives its assigned IP which matches the unbound record, then I can always access it by hostname.

Tailscale is another neat way. You can have ephemeral nodes. I want to learn how to do it with Docker, but apparently it's not too bad.

I have a small go binary that uses caddy and dns-sd on mac to have any kind of domain names on my local network (uses mdns) with https. Really nice for accessing websites from my phone.

https://github.com/DeluxeOwl/localhttps

This feels like more work than necessary, I'm not seeing an advantage. Ideally any kind of dev setup should be as contained/localized as possible, but if I'm having to modify OS components, then that feels like sprawl. Or, it's like /etc/hosts but with extra steps.

undefined

We have a separate domain registered, where you can add any wildcard subdomain, so webui.company-test.com and that will resolve to 127.0.0.1. Then we can do pretty much the same.

I'm not entirely sure how I feel about it, but at least it's on a completely separate domain.

Or you could have /etc/hosts resolve them to other addresses in the 127.0/8 block.

I have a public domain that resolves to a static lease in my internal network, which is running nginx proxy manager.

When I add a new site to my local setup, I just define a CNAME in Cloudflare and add an entry in Nginx proxy manager. It handles SSL via wildcard cert.

Wow! Today I learned that you can have subdomains of localhost. Never realized it!

Anyone care to shed why myapp.localhost:3000 (for the webapp I'm developing) is something that's useful for me rather than localhost:3000 ?

EDIT: on linux and don't use launchd, so I'd still the port number

undefined

Orbstack does all that pretty automatically. It also understands project structure / compose.

https://service.project.orb/

Nice, I've been wanting this - was just today talking about it.

Would be good to have the config all somewhere in my user's dir too.

Per user subdomains for their apps on localhost.

When using `.localhost` in the Caddyfile, you don't even need the `tls internal` line since that's assumed for that TLD.

We add a real actual DNS record for the local. subdomain pointing to 127.0.0.1

It works really well and means no setup on our developers machines

Why do you need gzip when it's running locally and being accessed on the same system?

I am old enough to remember

    localhost.localdomain

How do JS local dev setups use nice names like `local.drizzle.studio`?

I do the same at work (on premise machines on a private LAN).

wow this is hitting hacker news front page ? if we can change the hosts file - I want to propose you can have any domain name for local services.

undefined

you guys don't just memorize all your local ip's?

As a reminder, lacolhost.com and all subdomains will forever resolve to localhost (well for as long as I'm around at least)

excellent job.

Once again, .local should _never_ have been assigned to any organization. Just like .lan should also be reserved like the private IP blocks.

undefined

undefined