It's like someone should make a file... maybe in /etc ... and put short names for services in it... maybe it could be called /etc/services...

[delayed]

I know it's mixing of layers, but I can't help but feel the IPv6 transition missed the boat when they didn't just get rid of ports in the process. They've changed so much else anyway.

Want to run another webserver instance or whatever on your computer? Get the OS to allocate a new IP for it. Ports be damned.

Could be implemented in a backwards compatible way by requiring all IPv6 TCP/UDP traffic to use a fixed port number.

There's a simple method you can use with nginx and /etc/hosts, I wrote about it couple days ago [0]. I used it for an internal demo recently and realized that a new breed of devs have never seen a non localhost url run locally.

[0]: https://idiallo.com/blog/say-no-to-localhost3000-use-custom-...

I think this product demonstrates the atrophying of thought that results from too much LLM usage: design was obviously a long back-and-forth with a sycophantic LLM.

I find out what all my local servers are by `cat /etc/hosts`, because I put them in there. They run using an entry in the nginx config.

For short-lived stuff I don't even bother with that, I just use `whatever.localhost`.

If there was no LLM, author would have put a little more thought into this, maybe did a google search, and realised that all he needed were two shell scripts.

The more you use LLMs, the less you actually think

> The real annoyance is that it wasn’t just one machine. It was layers.

> I wanted a simple launcher for all the things that aren’t traditional desktop apps. Not Finder, Alfred or Raycast.

The entire damn article is like this - why would I trust software to run on my local machine when it was written by someone who did not even take care writing a blog post? How much care would they have possibly put into reviewing their vibe coded slop if they couldn't even bother to review their blog post?

Sounds similar to Vercel‘s portless CLI (https://portless.sh/)

*.localhost works btw

https://datatracker.ietf.org/doc/html/rfc6761#section-6.3

There is no need to come up with "local TLDs" like .vibe, .local, .test and so on -- there is already an industry convention! macOS and most Linux distros support subdomains of localhost, so <anything>.localhost works. You still need the reverse proxy to do the host->port mapping, but you save yourself local DNS fiddling.

I like localias[1] for this problem. Not only do you get nice aliases for all your local ports, but you also get nice Caddy-managed TLS certs for them

[1]: https://github.com/peterldowns/localias

I wonder why not use nginx and some local DNS settings to just serve all these local services under a new, local URL.

Not too long ago I had a similar issue and solved with that.

Why not resolve everything with UNIX sockets instead, that way you can have them named and scoped instead, hiding behind port 443, since it's mosly HTTP anyway.

This is a valid concern, certainly. I use kube for most things so it's not a problem, but my homeserver and its apps run on quadlets that I manage. In my case, I just added a README.md in the server account folder that each project's CLAUDE.md or whatever is configured to read. Then it selects a port and sticks that in the document and to be honest I have a few tens of services and it works. Haha, a direct replacement of machine for my own process.

I created something similar to help me spin up complex apps in multiple worktrees with full port orchestration: https://outport.dev/

Alternative https://github.com/peterldowns/localias

Granted no fancy UI to start and stop things but is it really needed?

Tbh this is not a single binary you need dnsmasq go and other things

This is literally what mDNS is for. Didn't even know that it was a thing until I needed it for some custom firmware I was writing recently. It's like DNS but also has service port advertisements.

Huh when I start a service in dev, I just click on the link in the terminal to visit the url. What is even the problem?

Vercel’s portless is a great alternative, but unfortunately it doesn’t work well with oauth flows. I’ve built portmap[0] to solve that. Also comes with skills which makes it work really great with coding agents (instructions in the readme).

[0] https://github.com/JonasKs/portmap

I use Cloudflare Tunnel so most of the products I build are exposed and listed there. I just add comments for those that aren't exposed (eg. browser extension dev port) to that file too. A single doc means coding agents know to look there and keep it updated too.

Not the same, but omeone recently posted this "port" tool here on HN: https://github.com/raskrebs/sonar

I've built this twice before. The main problem that I hit is that the AI agents suck at the process lifecycle management: leaving processes alive, starting the same daemon multiple times, etc.

From a brief glance over the code I like the approaches I see. Using the `/etc/resolver/` mechanism is a new trick to me!

The interesting part to me isn't the port numbers, it's the automatic service start/stop, including idle route shutdown.

I use subdomains on an OVH VPS, since I want to access the services outside the network, so I can use freshrss.mydomain.com. But anything that can rationalize port number sprawl is welcome.

I think about a decade ago pow did something similar, but using the .test domain, and perhaps ruby specific

https://github.com/basecamp/pow/tree/master

Aspire.dev should be mentioned here.

I use the tailscale services feature for this, added benefit is I get https.

I hate these signs of LLM generated texts so much!!

> The real annoyance is that it wasn’t just one machine. It was layers.

What is the benefit of using HTTPS for this particular use case?

I'm slightly annoyed that vite's default port isn't 8483

i have something like this too, currently a 60 line nodejs file

This project is essentially "give me some metadata & a command which takes env $PORT, and I'll handle the rest". Which is neat!

I am also sick of handling port numbers - I end up allocating them on a schema to different services, so for testing I can spool any VM/service combination and avoid crossover. But if I want the same service twice, ah...

It always fascinated me that ports don't have any kind of textual resolver, so you can bind to `:1234` and also say "please also accept `:foobar`". But that would itself require some kind of "port resolver" on a device, and that's another service to break and fix :)

It is funny, I just built something like this last week and named it "Network". Additionally it scans for any type of data packages arriving at the SonicWall and sees if they are approved by me or not. I am paranoid after using TP Link at home like a dumbass.

Bind to Port 0

What I do is use a hash function to derive port number from service name.

This is a neat approach. One thing I wonder about is how it handles services that use the same port number across different protocols (like 443 for both HTTPS and SMTPS). The /etc/services file approach has the same ambiguity, but at least it lists the protocol alongside the port. A lookup table that includes protocol would be more robust for mixed environments.