You can consider the use of Unix sockets (sockets as named files). There are lots of limitations but the most pervasive and frustrating of those is the general lack of support for them across apps.
You could set up Nginx and some local subdomains to reverse proxy to the intended applications, regardless of whether they're hosted on Unix sockets or plain ports, if that makes accessing them easier. It definitely makes them easier to make accessible outside of the local machine.
As for using Nginx, you should be able to install Nginx and enable its service and in that way immediately get a local HTTP server. You can then edit the config such that requests for the Host `myfiles.localhost` are `proxy_pass ...` to your bashbro server. Then `http://myfiles.localhost` in your browser should just work.
Ok, I appreciate your suggestions. But now I'm thinking about some utility where you can say:
run-http-service myfiles bashbro -s -p PORT
And then it would just allocate a new port (clash-free), invoke bashbro with the given flags and substitute PORT by the newly allocated port number, and such that it uses myfiles.localhost as the domain. And when bashbro exits, the port number is garbage collected. Somehow, it feels like this should already exist ...
Perhaps it would be enough to have a folder in your Nginx config that is imported by glob, and to have the port number and service name in the filename of each file in the folder. The contents might be templated out from some template (`envsubst` and `sed` are probably acceptable ways to fill the template). To allocate a service is to check if it's already allocated, then find the greatest port number in use and add 1 (the filesystem can help you with this if you name the files appropriately), then check to make sure nothing else is already listening, then write the config file and restart Nginx.
I would not bother with service management to the extent that you are checking to see if the process is still running. Maybe garbage collection is worth doing, you could do it in a single run of `lsof` (the temptation to do it with multiple should be resisted).
I think this does not exist because stuff like foreman/overmind have their own method for allocating ports per-project (add 100 for each line in the config file, set the PORT env var to that) as would any sort of production-ready solution.
But it is a fun idea. And perhaps it should exist.
No way to allocate port numbers without clashes ever. What I do is having a Ports.md in my personal knowledge base with all port assignments in my personal projects and networks: port, description, project link and/or service host:port. This works very well, I don’t have tens of thousands of projects so I’m not going to exhaust port numbers. I used to try to use Unix domain sockets as much as possible for anything fronted by nginx, but stopped bothering with that since I started centrally maintaining port assignment.
You can listen on an anonymous port. It's similar to how the kernel allocates a port for outgoing connections. It's very useful if you want to listen ephemerally, especially in tests. The downside is that you need your server to report which port it's actually listening on, and if it restarts, it will get a different port.
Is there a way to manage all these port numbers? And why can't we use strings, even if just locally?
And what do people use to allocate port numbers in a way that you'll never get clashes?