I’m considering the feasibility of using orgs to manage customer deployments. It would be too confusing to have multiple deployments for different customers in the same org, so the idea is to create an org for every new customer, deploying the dedicated resources in it.
For this to work, I’d need to have access to an API that would allow me at least to create and delete orgs. As a bonus, it would be nice to have access to the costs.
I think I saw something here before that this was possible with the GraphQL API, which I’m not particularly interested. Are there other APIs available to do this?
Hi @goncalo-oliveira, right now the GraphQL mutation is the only way to create an organization. You can still use it with a normal HTTP client; you don’t need any GraphQL libraries to use it.
I’ve read somewhere in other posts that this API wasn’t to be considered stable (breaking changes without notice, etc). Is that true, or could one consider this as stable? The last thing one would want was to break new deployments because the API changed.
We don’t offer any stability guarantees on the GraphQL API. That said, we don’t change it that often, because we use it from flyctl, but in theory change could come at any time.
You could also fork out to fly orgs create. We block really old versions of the flyctl CLI because we make a lot of changes to it and we don’t want users to risk app breakage, so you have to make sure to keep flyctl up to date (fly version upgrade). But in my opinion, GraphQL is currently your best option. You wouldn’t be the first customers to use it. And knowing about your use case helps us prioritize building stable APIs for these things.
Thanks for replying @ben-io. It’s not very reassuring, though…
We’ll give it some thought. I wonder if anyone has already suggested (or if it’s planned) a different way of organizing resources, other than creating a new organization, that is.
Also, do note that all additional organizations you create are started on the $5/mo Hobby Plan
Creating an org per customer is hard right now because you have to set up billing per org.
Most of our users doing multi-tenancy use a single org with 1 app per customer, each app on its own network. When you create an app via our (stable) Machines API you can pass a unique string representing the network.
Creating an org per customer is hard right now because you have to set up billing per org.
I agree. I don’t see it as ideal either. Although… in a way, for some cases (not necessarily ours), it might be advantageous to have a separate billing per customer.
Most of our users doing multi-tenancy use a single org with 1 app per customer, each app on its own network. When you create an app via our (stable) Machines API you can pass a unique string representing the network.
The thing is when you have more than one app per customer. In our case, each customer will need a minimum of 5 apps. Yes, we use a prefix or suffix to identify the customer, but still, if you need to go through the resources, it’s not perfect either. Sure, you can search using the prefix or suffix. And as you suggested, passing a private network id when creating the app works on isolating them per customer, but it’s less organized and more error prone, in my opinion.
For those reasons, I think that it would be a good idea to have another way of organizing resources inside an organization; a namespace, a resource group, whatever you want to call it. And yeah, ideally, share a private network through that namespace, group or whatever. Maybe I should post that as a new topic under wishlist.
Nonetheless, my original question was answered and I also gained additional insights. Thanks for that. They’ll help us define the best path for us.
