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 :)

  getservbyname(3)

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

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

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

Bind to Port 0

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'm slightly annoyed that vite's default port isn't 8483

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

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.

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.

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.

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

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