TFA links to a post by Kurt M at Fly which speaks to this, from a personal perspective. They are using sprites for a “production” workload - a tool for their family - and it’s persistent and accessible enough that they don’t have plans to move it.

https://fly.io/blog/code-and-let-live/

Thomas characterizes this as “believ[ing] that the future belongs to malleable, personalized apps”, which I think describes the use case perfectly. As a “barefoot developer” (to borrow another localfirst term, thanks Maggie Appleton), does every app really need more than a persistent home and an URL?

And so to your question “is the idea that these things can also/should run production workloads”, I believe “can” is right - but suspect that supporting “should” is on Fly’s roadmap.

They're an interesting middle ground between pure ephemeral dev environment and production environment. If your audience is the whole Internet, a Sprite won't scale today to serve it. But for most of the apps I'm building, the Sprite is actually fine for the foreseeable future. There's a ton of security automation stuff we're doing that a Sprite keeps up just fine with; the sandwich bracket I'm running downthread is also indefinitely fine on a Sprite.

On the other hand, if I took the sandwich bracket app and made it a generic "run a bracket" app and that app (inexplicably) got popular, I'd need to move it to a Fly Machine setup.

> Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?..

Yes.

They won't horizontally scale. They're pretty good for hosting my side projects! Not good for, eg, hosting the API that orchestrates Sprites.