8 ms·

.localhost Domains

• dd_xplore 2y ago
  Why do you need gzip when it's running locally and being accessed on the same system?
• deleted 2y ago
  [deleted]
• deleted 2y ago
  [deleted]
• chuckwnelson 2y ago
  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/
  • tapete 2y ago
    Luckily the easy fix is available: Do not use Safari.
• mohsen1 2y ago
  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.
  • EGreg 2y ago
    Actually, MacOS gives your computer a .local domain on DHCP and Bonjour usually
  • defraudbah 2y ago
    if you add your CA to the list of trusted certificate, everything will be fine. I do not recommend using custom certificates and would stick to http, unless you really know what you are doing
  • jeroenhd 2y ago
    I use .local all the time and it works just fine. For TLS I use my existing personal CA, but HTTP links don't cause issues for me. That said, I do use mDNS/Bonjour to resolve .local addresses (which is probably what breaks .local if you're using it as a placeholder for a real domain). Using .local as a imaginary LAN domain is a terrible idea. These days, .internal is reserved for that.
  • rcarmo 2y ago
    .local is mDNS/Rendezvous/Bonjour territory. In some cases it takes longer to resolve because your machine will multicast a query for the owner of the name. I use it extensively on my LAN with great success, but I have Macs and Linux machines with Avahi. People who don't shouldn't mess with it...
  • zamadatix 2y ago
    The reason is .local is a special case TLD for link-local networking with name resolution through things like mdns, by trying to hijack it for other use things might not go as you intend. Alternatively, .localhost is just a reserved TLD so it has no other usage to check. https://en.wikipedia.org/wiki/.local https://en.wikipedia.org/wiki/.local https://en.wikipedia.org/wiki/.localhost https://en.wikipedia.org/wiki/.localhost
  • deleted 2y ago
    [deleted]
  • Pxtl 2y ago
    Honestly, if I had my druthers there would be a standardized exception for .local domains that self-signed HTTPS certs would be accepted without known roots. It's insane how there's no good workflow for HTTPS on LAN-only services.
    • Spooky23 2y ago
      It’s actually gotten worse, you need to run a CA or use a public domain where it’s easy to get your internal naming schemes in a transparency log.
      • jeroenhd 2y ago
        The easy workaround I've seen companies use for that is by using a basic wildcard certificate (*.local.mydomain.biz).
    • jeroenhd 2y ago
      Technically speaking you could use DANE with mDNS. Nobody does it, browser don't implemented it, but you can follow the spec if you'd like. Practically speaking, HTTPS on LAN is essentially useless, so I don't see the benefits. If anything, the current situation allows the user to apply TOFU to local devices by adding their unsigned certs to the trust store.
      • mohsen1 2y ago
        Some more modern browser APIs only work in HTTPS. That's why I had to do it.
        • jeroenhd 2y ago
          Modern browsers only enable those APIs because of security concerns, and those security concerns aren't lifted just because you're connected locally. The existing exception mechanisms already work for this, all you need to do is click the "continue anyway" button.
      • 1wheel 2y ago
  • justin_oaks 2y ago
    I recommend using the .test TLD. * It's reserved so it's not going to be used on the public internet. * It is shorter than .local or .localhost. * On QWERTY keyboards "test" is easy to type with one hand.
• mjevans 2y ago
  Once again, .local should _never_ have been assigned to any organization. Just like .lan should also be reserved like the private IP blocks.
  • XorNot 2y ago
    Don't we have ".internal" for that?
    • jeroenhd 2y ago
      The TLD hasn't been registered, but it has been added to the list of reserved names so effectively that's the domain you should use if you don't want to use real names. .local also works fine, of course, if you enable mDNS and don't try to use normal DNS.
  • WorldMaker 2y ago
    .local wasn't assigned to an organization, it was assigned to mDNS: multicast DNS. mDNS is the ask everyone on the local network if they like to be called that name which used to be better known under Apple's brand/trademark Bonjour, but now is a true standard.
    • mjevans 2y ago
      Yes, but why couldn't they have assigned .mdns for that instead? Or even better given it it's own .arpa domain? E.G. .mdns(.arpa) rather than the .local TLD? ( https://en.wikipedia.org/wiki/.arpa https://en.wikipedia.org/wiki/.arpa )
      • WorldMaker 2y ago
        Because .local looks nice and is a better name/explainer for what mDNS does than the standard name or the old brand name? Because the old brand was already using .local even if Apple Devices were somewhat a minority at the time? At this point a lot of TLD changes are going to step on someone's project or home/business/private network. I think .local is a good name for mDNS. I appreciate why you maybe aren't happy with it, but don't share your concern.
• defraudbah 2y ago
  People used localtest.me back in the days :) https://weblogs.asp.net/owscott/introducing-testing-domain-localtest-me https://weblogs.asp.net/owscott/introducing-testing-domain-l...
• EGreg 2y ago
  Wow! Today I learned that you can have subdomains of localhost. Never realized it!
  • jeroenhd 2y ago
    .localhost is in the same list as .example and .invalid when it comes to reserved names: https://datatracker.ietf.org/doc/html/rfc2606 https://datatracker.ietf.org/doc/html/rfc2606 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.
    • EGreg 2y ago
      But is "foo.localhost" a valid domain name, for cookies and such?
      • jeroenhd 2y ago
        The RFC treats .localhost as a full TLD. I believe Windows does as well, as does Ubuntu (using default systemd-resolved), but macOS doesn't seem to resolve .localhost by default, necessitating the host file trickery. 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.
        • EGreg 2y ago
          We still need the Public Suffix List because of how inconsistent it was
        • 2y ago
• andrewstuart2 2y ago
  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/ https://datatracker.ietf.org/doc/rfc2606/
  • lima 2y ago
    For development, "localhost" has a convenience bonus: it has special treatment in browsers. Many browser APIs like Service Workers are only available on pages with a valid WebPKI cert, except for localhost.
  • jeroenhd 2y ago
    .test seems like an excellent choice for testing/debugging/developing applications, but for running services you want to use I'd stick to .internal these days, as it was reserved for local domains last year.
    • numbsafari 2y ago
      This is what I've done for years: doing app development using the .test TLD, and .internal for, well, internal services that are more like "production IT". I've had nothing but trouble with .local and .localhost. Specifically, .local is intended for other purposes (multicast DNS) and .localhost has a nasty habit of turning into just "localhost" and in some cases, resolvers don't like to allow that to point to anything other than 127.0.0.1. More recently, I've stuck to following the advice of RFC 6762 and use an actual registered TLD for internal use, and then sub-domain from there. I don't use my "production" TLD, but some other, unrelated TLD. For example, if my company is named FOO and our corporate homepage is at foo.com, I'll have a separate TLD like bar.com that I'll use for app development (and sub-domain as dev.bar.com, qa.bar.com, and maybe otherqa.bar.com as needed for different environments). That helps avoid any weirdness around .localhost, works well in larger dev/qa environments that aren't running on 127.0.0.1, and allows me to do things like have an internal CA for TLS instead of using self-signed certs with all of their UX warts. For "local network" stuff, I stick to ".internal" because that's now what IANA recommends. But I would distinguish between how I use ".internal" to mean "things on my local network" from "this is where my team deploys our QA environment", because we likely aren't on the same network as where that QA environment is located and my ".internal" might overlap with your ".internal", but the QA environment is shared.
• lima 2y ago
  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.
  • jchw 2y ago
    Yeah, I've been using localhost domains on Linux for a while. Even on machines without systemd-resolved, you can still usually use them if you have the myhostname module in your NSS DNS module list. https://www.man7.org/linux/man-pages/man8/libnss_myhostname.so.2.8.html https://www.man7.org/linux/man-pages/man8/libnss_myhostname.... (There are lots of other useful NSS modules, too. I like the libvirt ones. Not sure if there's any good way to use these alongside systemd-resolved.)
    • aib 2y ago
      I ended up writing a similar plugin[1] after searching in vain for a way to add temporary DNS entries. The ability to add host entries via an environment variable turned out to be more useful than I'd expected, though mostly for MITM(proxy) and troubleshooting. 1: https://github.com/aib/nss-userhosts https://github.com/aib/nss-userhosts
• accrual 2y ago
  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.
• radel 2y ago
  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
  • oulipo 2y ago
    and you're still setting up a proxy for the port forwarding?
• hardaker 2y ago
  You might check out .internal instead which was recently approved [1] for local use. [1]: https://en.wikipedia.org/wiki/.internal https://en.wikipedia.org/wiki/.internal
  • codetrotter 2y ago
    In that case I would prefer naming as <virtual>.<physical-host>.internal So for example phpbb.mtndew.internal And I’d probably still add phpbb.localhost To /etc/hosts on that host like OP does
    • nodesocket 2y ago
      I wrote a super basic DNS server in go (mostly fun and go practice) which allows you to specify hosts and ips in a json config file. This eliminates the need for editing your /etc/hosts file. If it matches a host in the json config file it returns that ip, else uses Cloudflare public DNS resolver as a fallback. Please; easy on my go code :-). I am a total beginner with go. https://github.com/nodesocket/godns https://github.com/nodesocket/godns
  • GrumpyYoungMan 2y ago
    The *.home.arpa domain in RFC 8375 has been approved for local use since 2018, which is long enough ago that most hardware and software currently in use should be able to handle it.
    • styfle 2y ago
      Why use that over *.localhost which has been available since 1999 (introduced in RFC 2606)
      • bravetraveler 2y ago
        From RFC 2606: The ".localhost" TLD has 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 The RFC 8375 suggestion (*.home.arpa) allows for more than a single host in the domain. If not in name/feeling, but the strictest readings [and adherence] too.
• _def 2y ago
  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.
• mococa 2y ago
  I do the same at work (on premise machines on a private LAN).
• thorvaldsson 2y ago
  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.
• jFriedensreich 2y ago
  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.
  • breck 2y ago
    [dead]
  • globular-toast 2y ago
    Source for this? Are you sure it's not your system resolver doing it?
    • kbolino 2y ago
      It's probably both. Browsers now have built-in DoH so they usually do their own resolving. Only if you disable "secure DNS" (or you use group policies) will you fall back to the system resolver anymore.
    • TingPing 2y ago
      There is a draft spec over it, Ill find it later, but they do hardcode it now and never touch dns.
    • jFriedensreich 2y ago
      Pretty sure its hard coded in the browser and never touches any resolvers. It does not work the same in safari for example.
• riffic 2y ago
  > 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.
• vlod 2y ago
  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
  • tgpc 2y ago
    maybe you're running a reverse proxy? it can direct you differently depending on how you refer to it
  • csciutto 2y ago
    The comparison is `myapp.localhost` vs `localhost:3000`. This is especially useful when you have web servers permanently running on your computer on ports, not just for momentaneous local development.
  • jeroenhd 2y ago
    Using real domain names lets you experience the web as it is in production. Localhost has a bunch of exceptions (i.e. HTTP URLs are treated as secure, CORS acts funny, etc.). Using domain names disables special handling of localhost URLs that'll help you spot problems before they hit production.
    • vlod 2y ago
      Thanks. This is the reason I wanted rather then convenience of not typing a port number (which I'd use a bookmark for, so I really don't care)
    • ghoshbishakh 2y ago
      Trick: edit yuor /etc/hosts file and add a domain name. Self sign a certificate and add it to your trusted certificate list. Or - use https://pinggy.io https://pinggy.io
  • deleted 2y ago
    [deleted]
  • gwd 2y ago
    It's `myapp.localhost` (without the port number). It's more useful because it's easier to allocate and remember a unique name than a unique port number.
• deleted 2y ago
  [deleted]
• AStonesThrow 2y ago
  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...
• mrweasel 2y ago
  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.
• donatj 2y ago
  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
  • oulipo 2y ago
    Can you expand on this? you redirect *.local.example.com to 127.0.0.1, and then how do you setup the local machine so that eg myservice.local.example.com hits the correct port? I guess you still need a proxy somewhere? or you specify eg myservice.local.example.com:3000 ?
    • donatj 2y ago
      It's not a redirect. It's an actual A record on the domain for local.example.com -> 127.0.0.1 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
• WhyNotHugo 2y ago
  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.
  • oulipo 2y ago
    Just did that on my mac and it seems to work? $ ping hello.localhost PING hello.localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.057 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.162 ms
    • Shywim 2y ago
      Not for me, MacOS 15.4: $ ping hello.localhost ping: cannot resolve hello.localhost: Unknown host
      • fimdomeio 2y ago
        I think I had mixed results on mac depending on the network I was connected to. I think it has something to do with ipv4 vs ipv6
        • g0db1t 2y ago
          Ironically for me it works on my MacOS laptop but not on my Debian 12 VPS
    • tedunangst 2y ago
      That's because your DNS server sends back 127.0.0.1. The query isn't resolved locally.
  • 2y ago
• nhance 2y ago
  As a reminder, lacolhost.com and all subdomains will forever resolve to localhost (well for as long as I'm around at least)
  • koolba 2y ago
    > As a reminder, lacolhost.com … I’m assuming that typo is intentional?
  • jeroenhd 2y ago
    > (well for as long as I'm around at least) Rather big caveat IMO. As a side note, your domain doesn't seem to have an AAAA record (which [.]localhost binds to by default on most of my machines, at least).
• bootcat 2y ago
  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.
• whalesalad 2y ago
  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.
• deleted 2y ago
  [deleted]
• jbverschoor 2y ago
  Orbstack does all that pretty automatically. It also understands project structure / compose. https://service.project.orb/ https://service.project.orb/
  • Tokumei-no-hito 2y ago
    broken link
    • zsoltkacsandi 2y ago
      It was an example how OrbStack puts together the domain.
    • jbverschoor 2y ago
      Docs at https://docs.orbstack.dev/docker/domains https://docs.orbstack.dev/docker/domains Forgot to add .local I see
      • jeroenhd 2y ago
        I hope Orbstack is also advertising those hostnames on mDNS, because using .local (or, seemingly worse, _relying_ on .local) will conflict with resolver logic on all kinds of devices.
        • jbverschoor 2y ago
          I'm not seeing any broadcasts. 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 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.
• VikingCoder 2y ago
  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.
• peterldowns 2y ago
  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 https://github.com/peterldowns/localias
  • CodesInChaos 2y ago
    How do valid certs for localhost work? Does that require installing an unconstraint root certificate to sign the dev certs? Or is there a less risky way (name constraints?)
    • sangeeth96 2y ago
      It's mentioned in the README: - If Caddy has not already generated a local root certificate: - Generate a local root certificate to sign TLS certificates - Install the local root certificate to the system's trust stores, and the Firefox certificate store if it exists and an be accessed. So yes. I had written about how I do this directly with Caddy over here: https://automagic.blog/posts/custom-domains-with-https-for-your-localhost-servers-on-macos/ https://automagic.blog/posts/custom-domains-with-https-for-y...
      • lxgr 2y ago
        > Install the local root certificate to the system's trust stores I really wish there was a safer way to do this, i.e. a way to tag a trusted CA as "valid for localhost use only". The article mentions this in passing > The sudo version of the above command with the -d flag also works but it adds the certificate to the System keychain for all users. I like to limit privileges wherever possible. But this is a clear case of https://xkcd.com/1200/ https://xkcd.com/1200/. Maybe this could be done using the name constraint extension marked as critical?
• silvanocerza 2y ago
  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/ https://www.silvanocerza.com/posts/my-home-network-setup/
  • chippiewill 2y ago
    For internal networks the `internal` tld is reserved
    • silvanocerza 2y ago
      I know. Though I wanted a short URL, that's why I used .it any way.
• octagons 2y ago
  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-local-as-your-domain-name-extension-is-a-bad-idea-4828 https://community.veeam.com/blogs-and-podcasts-57/why-using-...
  • hobo_mark 2y ago
    I added a fake .com record in my internal DNS that resolves to my development server. All development clients within that network have an mkcert-generated CA installed. Not so different from you, but without even registering the vanity domain. Why is this such a bad idea?
    • thot_experiment 2y ago
      I alias home.com to my local house stuff. I don't really understand why anyone thinks it's a bad idea either.
      • matthewaveryusa 2y ago
        It's not a terrible idea. On a large scale it can lead to the corp.com issue: https://krebsonsecurity.com/2020/02/dangerous-domain-corp-com-goes-up-for-sale/ https://krebsonsecurity.com/2020/02/dangerous-domain-corp-co... Honestly for USD5/year why don't you just buy yourself a domain and never have to deal with the problem?
      • deleted 2y ago
        [deleted]
    • szszrk 2y ago
• mholt 2y ago
  When using `.localhost` in the Caddyfile, you don't even need the `tls internal` line since that's assumed for that TLD.
• pwdisswordfishz 2y ago
  Or you could have /etc/hosts resolve them to other addresses in the 127.0/8 block.
• subculture 2y ago
  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.
  • tetrisgm 2y ago
    Thanks for the laugh. I wonder what test@gmail.com gets hahaha
    • isleyaardvark 2y ago
      For anyone unaware, the domain 'example.com' is specifically reserved for the purpose of testing, so you don't have to worry about some rando reading emails sent to "test@gmail.com"
      • watusername 2y ago
        I don't get it. What does gmail.com have to do with example.com?
        • mbreese 2y ago
          Is a public service announcement. If you’re using test@gmail.com to actually test something, you should probably be using test@example.com. Not everyone knows that example.com exists for these purposes. That is of course unless you really intend to send an email to someone at test@gmail.com.
• sigil 2y ago
  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!
  • ku1ik 2y ago
    This is neat!
  • hn92726819 2y ago
    I'm not that familiar with nginx config. Does this protect against path traversal? Ex: host=../../../docker.sock
    • sigil 2y ago
      nginx validates hostnames per the spec, and to your question specifically it rejects requests that would put a slash in $host: https://github.com/nginx/nginx/blob/b6e7eb0f5792d7a52d2675ee3906e502d63c48e3/src/http/ngx_http_request.c#L2221 https://github.com/nginx/nginx/blob/b6e7eb0f5792d7a52d2675ee...
• threatofrain 2y ago
  How do JS local dev setups use nice names like `local.drizzle.studio`?
  • Jnr 2y ago
    That is an external domain. Javascript on that site connects to the locally running drizzle service.
  • deleted 2y ago
    [deleted]
• joey_spaztard 2y ago
  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.
  • jrockway 2y ago
    The last time I tried this, it works on Linux but not on Mac OS. Given all the discussion about launchd, I'm guessing they need it to work on Macs.
• smjburton 2y ago
  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.
  • shadowpho 2y ago
    > You'll still keep your services private to your internal network, Is that a new thing? I heard previously that if you wanted to do DNS/domain for local network you had to expose the list external.
    • smjburton 2y ago
      It's not, just a different way of satisfying the certificate challenge. Look into a DNS-01 challenge vs a HTTP-01 challenge. Let's Encrypt has a good breakdown: https://letsencrypt.org/docs/challenge-types/ https://letsencrypt.org/docs/challenge-types/.
      • shadowpho 2y ago
        Gotcha and that lets us avoid to expose internals? that seems like a win win win, I should totally do this!
        • smjburton 2y ago
          Yeah that's right. You can use something like https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns or something similar to validate the DNS-01 challenge.
  • qwertox 2y ago
    I was on a similar thought process, but this leaves you only with the option to set the A record of the public DNS entry to 127.0.0.1, if you want to use it on the go. Though you could register a name like ch.ch and get a wildcard certificate for *.ch.ch, and insert local.ch.ch in the hosts file and use the certificate in the proxy, that would even work on the go.
• deleted 2y ago
  [deleted]
• nine_k 2y ago
  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.
  • justin_oaks 2y ago
    I'd recommend using some other reserved IP address block like 169.254.0.0/16 or 100.64.0.0/16 and assigning it to your local loopback interface. (Nitpick: you can actually use all of 127.0.0.0/8 instead of just 127.0.0.0/24). I previously used differing 127.0.0.0/8 addresses for each local service I ran on my machine. It worked fine for quite a while but this was in pre-Docker days. Later on I started using Docker containers. Things got more complicated if I wanted to access an HTTP service both from my host machine and from other Docker containers. Instead of having your services exposed differently inside a docker network and outside of it, you can consistently use the IP and Ports you expose/map. If you're 127.0.0.0/8 addresses then this won't work. The local loopback addresses aren't routed to the host computer when sent from a Docker container; they're routed to the container. In other words, 127.0.0.1 inside Docker means "this container" not "this machine". For that reason I picked some other unused IP block [0] and assigned that block to the local loopback interface. Now I use those IPs for assigning to my docker containers. I wouldn't recommend using the RFC 1918 IP blocks since those are frequently used in LANs and within Docker itself. You can use something like the link-local IP block (169.254.0.0/16) which I've never seen used outside of the AWS EC2 metadata service. Or you can use the carrier-grade NAT IP block (100.64.0.0/16). Or even some IP block that's assigned for public use, but is never used, although that can be risky. I use Debian Bookworm. I can bind 100.64.0.0/16 to my local loopback interface by creating a file under /etc/network/interfaces.d/ with the following auto lo:1 iface lo:1 inet static address 100.64.0.1 gateway 100.64.0.0 netmask 255.255.0.0 Once that's set up I can expose the port of one Docker container at 100.64.0.2:80, another at 100.64.0.3:80, etc. [0] https://en.wikipedia.org/wiki/Reserved_IP_addresses https://en.wikipedia.org/wiki/Reserved_IP_addresses
• ipkstef 2y ago
  you guys don't just memorize all your local ip's?
  • justin_oaks 2y ago
    In my day we memorized IPs AND ports. 10.24.67.22:78342 was to access our bug tracker and 192.168.240.17:21282 was for our CVS repository! Seriously though, one of the first things I did when I was hired as the sysadmin for a small company was to eliminate the need for memorizing/bookmarking ip-port combos. I moved everything to standard ports and DNS names. Any services running on the same machine that needed the same ports were put behind a reverse proxy with virtual hosts to route to the right service. Each IP address was assigned an easy-to-remember DNS name. And each service was setup with TLS/SSL instead of the bare HTTP they had previously.
• djanowski 2y ago
  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 https://[project].localhost No daemons, and the only piece of configuration is adding a file to /etc/resolvers: https://github.com/djanowski/hostel 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!
• jdprgm 2y ago
  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.
• mmanfrin 2y ago
  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.
• joeyguerra 2y ago
  excellent job.
• flowerthoughts 2y ago
  I just use https://myapp.localhost:2948 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 https://datatracker.ietf.org/doc/html/rfc6761#section-6.3
• _odey 2y ago
  Note: browsers also give you a Secure Context for .localhost domains. https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts 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).
  • bolognafairy 2y ago
    Well shit. TIL. Time to go reduce the complexity of our dev environment.
    • jrvieira 2y ago
      you should never trust browsers default behavior 1. not all browsers are the same 2. there is no official standard 3. even if there was, standards are often ignored 4. what is true today can be false tomorrow 5. this is mitigation, not security
      • wutwutwat 2y ago
        1. not all browsers are the same they are all aiming to implement the same html spec 2. there is no official standard there literally is > A context is considered secure when it meets certain minimum standards of authentication and confidentiality defined in the Secure Contexts specification https://w3c.github.io/webappsec-secure-contexts/ https://w3c.github.io/webappsec-secure-contexts/ 3. even if there was, standards are often ignored major browsers wouldn't be major browsers if this was the case 4. what is true today can be false tomorrow standards take a long time to become standard and an even longer time to be phased out. this wouldn't sneak up on anyone 5. this is mitigation, not security this is a spec that provides a feature called "secure context". this is a security feature. it's in the name. it's in the spec.
        • kbolino 2y ago
          Notably, assuming conformance to this standard, a browser might still not treat localhost domains as trustworthy if it has reason to believe they can be resolved remotely. However, I'm not sure in what environments this is likely to be the case, especially with browsers implementing their own DNS over HTTPS.
• dh1011 2y ago
  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 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?
  • globular-toast 2y ago
    You need to install a DNS server in your network and configure everything to use it (probably via DHCP). Then you can configure whatever you like. Dnsmasq is quite easy to get started. There are handy integrated solutions like pihole that combine DHCP and DNS. I run things like this on my router (opnsense).
• globular-toast 2y ago
  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 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).
• deleted 2y ago
  [deleted]
• staticelf 2y ago
  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.
• politelemon 2y ago
  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.
  • sabslikesobs 2y ago
    Yes, I felt like this too. I like that it's cute and how it removes the need to inject ports into any "this is my URL" environment variables, but I agree it does sound like "sprawl." Browser bookmarks serve the same purpose.
• austin-cheney 2y ago
  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.
• rockmeamedee 2y ago
  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 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 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.
• stuaxo 2y ago
  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.
• techn00 2y ago
  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 https://github.com/DeluxeOwl/localhttps
• egberts1 2y ago
  I am old enough to remember localhost.localdomain