Hm… The biggest recent development is that there’s now a Pulumi provider in the works, which Fly.io has been very supportive of:
Probably the best way to help move the overall declarative cause forward would be to lend a hand in testing that one out as well—and giving feedback, etc.
It is mainly an architectural judgment rather than the difficulty of implementation, from what Fly has said themselves in the past.
We don’t have a Terraform provider anymore, and that’s intentional. It’s not a great fit for how our platform works. This guide is about how to get a Terraform-like experience using the tools that do fit.
[…]
But when it comes to the Machines API specifically, Terraform was always working at a bit of a mismatch since it tries to express an inherently imperative lifecycle in a declarative model. The Machines API gives you fine-grained control and flexibility that didn’t map cleanly to Terraform’s abstractions. With a little effort, you can build exactly what you need, and avoid being boxed in by someone else’s idea of what an app should look like.
If you’re rebuilding that tooling now, let us know what you’re working on. We might be able to help, or at least learn something from it.
https://docs.fly.io/blueprints/infra-automation-without-terraform
There was actually a strong pro-declarative faction within the company for a while, from what I hear, but the (mostly) imperative side won out in the end.
(That’s simplifying the story a little, I’m sure, 
.)