Tried it. Docker wasn't preinstalled so asked Claude to do it and make sure it's running (supervisord or the likes isn't preinstalled).
It neatly did so and "registered" it as a sprite service. Then I exited my session, waiting for the sprite to go idle, but I don't think it ever does.. Still have it active. Don't know how to idle it.
Can't tell for sure if this means I'm losing credits as there is no billing usage shown anywhere.
Also waiting for the moment where I can launch a sprite from another's checkpoint.
There's no way to stop sprites from the CLI.
Supposedly they auto-stop when inactive.
But I've tried multiple times and they don't stop, and it's not just Docker that prevents them from stopping.
I created a new sprite and installed ffmpeg. Then exited. Next day I run `sprite ls` and it's been running continuously for 23 hours.
No way to tell if I'm being billed for it or not.
And the per-hour pricing is extremely expensive.
So for now it's `sprite destroy -s spritename`.
Maybe I'll check it out again in a few months after the fly team has iterated on this a few times.
Ok so, "running" sprite status has had some cache consistency issues. You're not being charged for idle sprites, but they may show as "running" even when you're not using them. The UX has improved, and it reliably shows what you expect. Some of the existing sprites need an environment upgrade, but you'll see those improve over the next few days.
Just use container-os as your runtime image: https://hub.docker.com/r/miget/container-os
and you should be good
We had a bug where some sprites would fail to properly suspend while entering their suspended state. You're not eating into credits so no worries there. We've been rolling out a fix across the fleet today so you should be seeing proper status soon.