Great questions.
You are responsible for exiting on inactivity. The Golang proxy is an example of how you might do that. It runs in the container then exits when there aren’t any connections. You could monitor for inactivity externally, but we think it’s simpler to build that into the container itself.
One problem here is this is probably dumber than you think. There’s no inactivity monitoring, really. You just make your process exit. This is what the Go proxy example is doing. It runs as a process supervisor and kills your app process on idle.
You can run per user machines a couple of ways. It mostly depends on how unique the execution environments need to be.
In some cases, you will want to build a whole new Docker image per user. If you’re doing that, it’s probably best to put each user in their own Fly app, keep a list of Machines <-> Users, and start them by ID.
In other cases, the execution environment is very similar, you may just want to run a small script on behalf of a user. If you can encode what you need in the URL, you can have us route you to a machine to run that command. I’ve been working on a demo of this general pattern here: GitHub - superfly/bfaas: Bash functions-as-a-service
I love that you’re working on this so early. Our docs will get a lot better the more we can learn what you’re doing. If you’re interested in describing your use case here we can give some pretty precise recommendations.