Best practices for dynamically spinning up apps on behalf of our end users

1

Hello Fly folks, I’m trying to understand if my use case is supported and what the best practices are.

What I’m trying to do

We have a product that makes it very easy to create Node.js apps + SPA frontends locally. We want to create a cloud-hosted version where users can deploy these apps through our service with one click of a button. I am investigating if I can use Fly as the backend where we deploy these apps (seems way more fun than AWS :).

TLDR: we want to deploy N small apps dynamically on behalf of our users.

What I want to know

  1. Is this a supported use case?
  2. What, if any, limits are there? Can we spin up tens of 1000s of apps? More? Is there a ceiling?
  3. Are there recommended ways to handle billing in these cases? If each end-user app is also a Fly app, is there an API where I can get the billing details for each app individually?
  4. What other challenges or gotchyas should I be aware of for this use case?

Rough architecture plan

Does the following sound right? Are there best practices I’m missing?

  1. We create a Fly app in our Fly organization for each app created by one of our end-users.
  2. The Fly app has its own custom network to be isolated from other end-user apps (later, we can also assign custom domains to these apps)
  3. We can spin up N machines or other resources under this app, though most deployments will probably have the lowest tier shared CPU etc to start. We autoscale it to 0 when it’s not in use to avoid consuming unused resources and reduce charges.
  4. We charge our end-users by adding up the cost of all the apps they deployed.
  5. We use the REST API to implement the above programmatically

Anything else I should know?

Thank you :pray:

1 Like
2

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.