We’re deploying a single image to a machine via “image=” property within our fly.toml file. We know in advance that image is compiled only for x86 CPU architectures; it will not run on ARM architectures. Thus far, no problems at all. It runs and serves.
However, can fly.io guarantee that over multiple teardowns and redeploys it will always be provisioned the correct x86 CPU architecture?
Thanks!
Matt
great question! this is something we can currently guarantee-- there’s no ARM in our fleet.
It’s not something I’d want to guarantee indefinitely, since ARM is something folks have asked for several times over the years.
That said, it’s not currently something we’re actively planning, and we’d definitely post about it here and in the newsletter if we ever do add some, so you wouldn’t be without advance notice of the change.
Makes sense and thanks! Should you get there, perhaps I can be the first (or another) to request:
Provisioning that checks whether requested container workload can run on ARM before provisioning it
User-available switch to restrict provisioning to x86 only OR
Both
Really appreciate the dynamite fly.io platform. We have big plans for how fly.io helps our company.
if we ever provide architectures other than x86, the user will have to explicitly choose the architecture to use (or default to x86).
this is a bit of an unusual thing to ask - I’m curious if you’ve found other platforms dynamically schedule workloads on different CPU architectures?
Yeah, good question. No, I’ve not seen that, and considering the number of different ways fly.io supports automated deployment, I think it might be hard to architect. I was only asking because fly.io DOES offer so much intelligence, for example by inferring some infrastructure needs from source code repo alone. And I didn’t want the platform someday to think it was helping by assigning ARM when actually that wouldn’t work.