Pulumi Provider

1

Pulumi is similar to Terraform, but it seems to be more flexible. Might be good to have a Fly.io provider. I’d use this for Coder if they implement it on their end.

4 Likes
2

Agreed. I might have a look at that if nobody else does. Not sure what’s involved though. I assume Pulumi builds their own providers and would accept external ones they haven’t already built in-house.

1 Like
3

Yeah it definitely seems a bit strange, to be on their official registry you’d need to fill out some contact form, and publishing packages seems to be a bit involved.

But also there’s a bridged provider package type that allows you to use Terraform as a Pulumi provider? Not sure what the implications on the flexibility of that would be.

And it seems you can also convert Terraform to Pulumi? Truly weird stuff.

4

Interesting. Maybe Fly have to instigate it.

I sae the Terraform approach too. Fly do have a Terraform provider so maybe that would be the way to get it into Pulumi too. Without duplicating a load of stuff.

5

Fun fact, a pulumi provider has been attempted but we ultimately chose to set it aside for now. Here is why: as you both correctly noted Pulumi does have a mechanism to bridge a Terraform provider to Pulumi. To understand why we can’t use that to bridge our provider we need to understand a bit of the history behind Terraform Provider development.

When Terraform originally allowed for external providers, developers could use something called the Terraform SDK, the Terraform SDK became SDKV2. The SDK/SDKV2 had a bunch of problems/rough edges that led to the Terraform Plugin Framework being created. Most major TF Providers are still built on the SDK, while new providers are encouraged to use the new Terraform Plugin Framework. Because the Fly.io Provider was a greenfield implementation, I used the new Framework.

That brings us back to the Pulumi problem. GitHub - pulumi/pulumi-terraform-bridge: A library allowing providers built with the Terraform Plugin SDK to be bridged into Pulumi. only supports bridging providers built with the old SDK, not the new Framework. Now, it is possible to do a “Pulumi Native” provider, but that feels a lot less supported than the bridge and has several ergonomics problems that made it not fun to work with.

Not to say it can’t be done! We probably just won’t be the ones doing it for now :slight_smile:

5 Likes
6

@DAlperin Thanks, that explains it.

1 Like
7

We’d also love a Pulumi integration here.

An fresh update I found is that Pulumi team has a preview version of a bridge for the new Terraform Plugin Framework!

I tried a few days back to test it on the Fly.io terraform provider out but got what looks like some version mismatch errors (the Pulumi bridge was using a newer version of TPF than what the fly provider was using). I will try to dig it up if useful.

Update: here’s a draft PR with the details.

4 Likes
8

I just ran across GitHub - dirien/pulumi-fly: Pulumi provider for Fly.io. I haven’t tried it yet but in theory this should do what we want.

9

I tried using the pulumi provider for fly mentioned above but it errors out when importing existing apps.

10

Is there any update about Pulumi, Terraform/OpenTofu or other declarative or multi-provider deployment tools?

11

We aren’t able to support an official terraform provider at the moment, but there may be some active community forks - Forks · fly-apps/terraform-provider-fly · GitHub.

Can you tell us more about how you want to use Pulumi or Terraform?

12

If in the future Fly creates a Pulumi provider, I’d be interested in using Pulumi Cloud for:

  • Preview apps for PRs. Although https://flycd.dev/ looks like a great community project, I’d personally prefer to use something more mature, robust, documented, and with a larger community behind it, like Pulumi. It also just seems weird to me to have provider-specific CD systems vs. generic CD systems that can connect to the desired providers. That’s not a knock on FlyCD, which is providing a great service in the absence of Fly having integrations with Pulumi, Terraform, etc.
  • Auto-patching (redeployments) when a Docker base layer is updated. For example, when Ubuntu releases security fixes. I don’t know if Pulumi Cloud offers a trigger that gets called when base layers are updated in the container registry, but I think they have a REST endpoint for pulumi up that when called detects if anything (including IaC code, app code, or base layers) changed and only redeploys if a change is detected. In which case, the only other piece that would be needed is something that calls that REST endpoint on cron, which would be trivial to do in a GitHub action or similar.
  • Initializing a Volume with the desired set of initial files would make more sense to me as a Pulumi program than having the main Fly app need to do it as part of its entrypoint.
  • Coordinating deployments of an app that uses Fly resources plus resources from other Cloud providers. For example, if I have a Fly app for the back-end and a Deno Deploy app for the front-end. Or if I’m adding Netlify for an HTTP cache in front of a Fly app. Those examples might be moot since neither Deno Deploy nor Netlify have Pulumi providers (and might not need them since they try to abstract you away from infrastructure anyway), but you get the idea.
1 Like