You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 1, 2024. It is now read-only.
Great work on creating this terraform provider: it makes it easier to manage fly.io resources by code, which is great when working in teams.
A challenge however, is to keep up this terraform provider with the fast evolving fly.io resources and services. For example, shared IPs are currently not (yet) supported.
Therefore, I suggest to use the go implementation of flyctl for the fly.io API. This eases the adoption of new features and changes, and as Fly.io organisation you have only one implementation to maintain.
If this is something you agree on, I am happy to give it a shot rewriting the provider to the flyctl implementation.
The text was updated successfully, but these errors were encountered:
We also think this is the correct approach, at least until Fly if/ever decides on a stable public API. I took a stab at https://github.com/getenv/terraform-provider-fly but it's really just for our internal use and I'm copy/pasing graphql queries which isn't great. However, it does seem like the api package in flyctl exposes enough to do a proper wrapper. I'm glad to join forces on an active provider, this project seems a bit dormant.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi there,
Great work on creating this terraform provider: it makes it easier to manage fly.io resources by code, which is great when working in teams.
A challenge however, is to keep up this terraform provider with the fast evolving fly.io resources and services. For example, shared IPs are currently not (yet) supported.
Therefore, I suggest to use the go implementation of flyctl for the fly.io API. This eases the adoption of new features and changes, and as Fly.io organisation you have only one implementation to maintain.
If this is something you agree on, I am happy to give it a shot rewriting the provider to the flyctl implementation.
The text was updated successfully, but these errors were encountered: