I don't know about the GP, but I would actually like to be able to keep the pod alive while it's doing some processing, in case the user wants to run a long process, go away, then come back later when it's done. Yes, I know there are other tools for orchestrating pure batch jobs, but I imagine some applications are a mix of interactivity and long-running computations.

That makes sense. We currently don't support that directly, although we have a “grace period” which is how long it waits for a service to be idle before shutting it down. You could set to a very high number and then have the service manage its own termination when it became idle. But that's a bit of a hack, first-class support for that use case is something I'll think about.

Here's one way you could implement first-class support for this use case. It's a bit of a hack, but it's simple. IIUC, the proxy is a sidecar, meaning it runs in the same network namespace as the main container. So the proxy could listen on a particular port on localhost, and as long as a connection is open to that port, the sweeper wouldn't touch that pod. Then the main container would just need to open a TCP connection for the period of time that it wants to make sure it stays running.

If I understand correctly, Sweeper clears up sessions that haven't received a request in a certain amount of time. Essentially the use case would be to leave the session running until I ask Sweeper to clear it via an API request.

Just to illustrate where I'm coming from, what I have so far mimics the pm2 cli as an API with built-in reverse-proxy, with create (similar to init), reload, restart, start, stop and delete.