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...

  $ getent services gopher
  gopher               70/tcp

  * URL rejected: Port number was not a decimal number between 0 and 65535
  * Closing connection
  curl: (3) URL rejected: Port number was not a decimal number between 0 and 65535

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 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.

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/

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.

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.

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.

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

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