Future of fly terraform provider?

[kdevan]

Just to clarify, since #253 has been added which says, "This project is not currently maintained, and is not a recommended method of deployment to Fly.io.", I assume this means no one who works at fly is focusing on this provider? And if so, does that also mean PR's will not be accepted?

Is forking the recommended path forward for someone looking to update the provider as needed?

Is there another method recommended for automating fly infrastructure?

[kdevan]

Also, just thought I would ask, is there any chance a fix for volumes could go through and then the repo is unmaintained after that? I think that would allow many operations to continue with that one fix.

[pi3ch]

It seems nobody is looking at this. Today also creating machine using terraform start failing. Unsure if something change on Fly api side. Is there an active fork?

Create request failed: 401 Unauthorized, {"error":"malformed authorization header"}

[mootari]

@gedw99 You can find the official answer at the top of the Readme:

This project is not currently maintained, and is not a recommended method of deployment to Fly.io.

[fermentfan]

What the actual fuck guys. I chose Fly, because it allowed me to have my base setup in Terraform. Now I see a breaking change and need to see this happening as a paying customer. Instability of the platform I might accept for the moment, but deciding for such a regression in your functional offering really makes me question whether I still want to use Fly. I need to have access to my static IPs in my Terraform setup. I really dislike managing the certs without having it connected to my CloudFlare instance. And we also rely on machines being spawned, which is now broken.

And then there isn't even an official replacement. Advising to "use the CLI or API" is missing the complete point.

[pi3ch]

I am keeping a fork branch + terraform provider with things that I need. still works but It doesn't have all the fixes. PR welcome. https://github.com/pi3ch/terraform-provider-fly

[otterDeveloper]

What the actual fuck guys. I chose Fly, because it allowed me to have my base setup in Terraform. Now I see a breaking change and need to see this happening as a paying customer. Instability of the platform I might accept for the moment, but deciding for such a regression in your functional offering really makes me question whether I still want to use Fly. I need to have access to my static IPs in my Terraform setup. I really dislike managing the certs without having it connected to my CloudFlare instance. And we also rely on machines being spawned, which is now broken.

And then there isn't even an official replacement. Advising to "use the CLI or API" is missing the complete point.

I found out they existed looking through the Terraform Registry

[mattfysh]

I think I came to realize fly is more suited to hobbyists and prototypes, which is why all of the tooling is geared towards the CLI / manual work and no (longer) any devops/IaC type tooling

If you're using Terraform, Pulumi, or any other IaC framework, you're probably beyond the level of maturity offered by fly. I've recently started learning Kubernetes and am now migrating some of my services off of fly, particularly the ones that integrate heavily with the rest of my cloud stack. this has already solved a bunch of problems I was having with fly e.g manually managing secrets via the CLI was becoming cumbersome and error-prone.

I started with the EKS tutorials from Pulumi and realized k8s is nowhere near as scary as people make out. I had migrated an app over to EKS within a couple of days. If you're serious about managing all your infrastructure as code (especially their interdependencies, particularly secrets and connection strings) then I suggest fly might not be the choice for you