I’m exploring running a web app in a sprite that makes use of background jobs. I think these are just managed by the main process. However I can see that the background jobs don’t finish unless I click around the app, or log into the sprite console — I assume that the sprite is going cold if there isn’t an active request? Is there any way to allow the app to keep itself alive while it’s actively processing a background job?
I’m not a sprites user, so take this with as much salt as you need. I assume here, “background jobs” takes the Unix meaning of the phrase, i.e. processes running on the same box, which have become disconnected from the console, and for which one can reconnect using fg.
I would be slightly inclined to use traditional machines for this. You could have one running permanently (runs any job based on an API call) or you could create a new machine per job. I quite like the latter approach, since in Docker/Firecracker you can just exit your main process, and this stops the container/machine entirely. Thus, they tidy up their compute resource automatically, when they no longer need it.
It’s a java app so I think the background jobs are part of the same unix process that runs the JVM, rather than a true separate process. I’m trying to run this app more or less off the shelf. It’s been super convenient to have a Sprite that has all the necessary bits in it, with Claude to help me edit the configs and install services. But it has this downside that it shuts down if there’s no active request or console. I can move it to Fly machines instead, I don’t think that’s too tricky, but it has the downside then of a lot more ongoing cost. This is an app with usage in single-digit hours per month, so I really want something that scales down to $0 when it’s dormant.
you can use the tasks api to keep a sprite alive. something like this should work: sprite-env curl -X POST /v1/tasks -d '{"name": "my-task", "expire": "1h"}'