Indeed, but since this was built by @chrismccord and his team, you can always ask them and they will be able to give you support. Ease of integration is a selling point for this solution.
D4no0
chrismccord
Creator of Phoenix
mruoss
Apologies, my last post might have come over the wrong way. I didn’t mean to say that Fly.io was slower than you presented, Chris. I was only trying to say that starting any machine can fluctuate e.g. if the controller starting it has to download a very big container image.
Answering the initial question is definitely much harder on Kubernetes because it probably varies much more.
1
chrismccord
Creator of Phoenix
No worries at all – I didn’t take it that way 
Start times fluctuate for sure based on what docker image layers are cached locally or not. On fly, machine creates will favor a host with the current image cached if that host has available capacity, falling back to pulling from a region registry. Also one option for a faster FlyBackend would be to precreate the machines and then stop (or suspend) them. Then growing the flame pool is a machine start instead of create, which would bring starts down to 500ms. I assume the k8s orchestrator is doing something along these lines.
I have avoided this so far on the FlyBackend because it requires more orchestration and failsafes to avoid orphaning resources, and the cold boots are Fast Enough™ . That said, with the new machine suspend features we can technically have a machine back up and running sub 100ms. I still favor the cold creates for simplicity, but I would be open to an option like eager: true which precreates the fly machines if folks really want it.
4