Is it possible to make dynamic Multi-Machine Deployment with Unique Subdomains using Fly.io API?

Questions / Help
, , ,
1

Is it feasible to dynamically deploy multiple machines from a single image, each with its own unique subdomain, using the Fly.io API? Our use case involves creating separate, accessible instances on-demand, potentially running concurrently, and then terminating them when no longer needed. Any guidance on best practices or limitations would be appreciated !!
(each machine host it’s own backend with unique url to access the backend)

2

Yes, this is one of the use cases we intended with fly-replay. You run one app that decides where to route traffic, and then individual apps (or machines, see caveats) for backends.

The request sequence would look like this:

  • Request comes in to router app
  • Router app checks subdomain against cached list of backends
  • Router app responds with fly-replay: <desired-backend>

The basic setup looks like this:

         ┌────────────────────────────────┐           
         │            router              │           
         │          fly-replay            │           
         └─┬──────────────┬─────────────┬─┘           
           │              │             │             
           │              │             │             
           │              │             │             
           │              │             │             
           │              │             │             
           │              │             │             
┌──────────▼───┐   ┌──────▼───────┐   ┌─▼────────────┐
│              │   │              │   │              │
│  abc.domain  │   │  xyz.domain  │   │  pdq.domain  │
│              │   │              │   │              │
└──────────────┘   └──────────────┘   └──────────────┘

Now, you can do this with multiple machines (fly-replay: instance=<id>), but in most cases it’s better to create multiple apps, one per backend. This lets you isolate each one to its own private network.

1 Like
3

Here’s a small example:

1 Like
4

@kurt @lubien

Thanks for the quick reply! I’d love to get your opinion before deciding which path to take. Let me provide more context about our use case:

We’ve built a Zoom meeting bot with the following requirements:

  • Each instance needs ~4GB RAM and 2 cores to run smoothly
  • We need to boot a machine only for the duration of a meeting
  • Our initial design involves spawning one machine per meeting for better isolation
  • All machines run the same Docker image but with different ENV variables
  • Each machine requires a mount

Our main challenge now is deploying these machines and scaling up/down before and after meetings.

Given these requirements, I’m wondering:

  1. Does this use case fit better with fly-replay, or should we create apps dynamically?
  2. Can Fly.io handle rapid scaling of machines with these specs (4GB RAM, 2 cores, mount)?
  3. Are there any limitations or best practices we should be aware of for this kind of dynamic deployment?

Any insights you can provide would be greatly appreciated as we finalize our production architecture. Thanks!

5

That bot architecture should work really well with the fly replay setup. We use fly-replay to establish long lived websocket connections and it’s really nice.

You can actually hold a request in the router, create an app / machine, and then respond with fly-replay to it, if you’d like.

You can create and remove machines very quickly. Same with volumes. One thing to consider is how many moving parts are involved in our infrastructure:

  1. Create machine touches a lot more places than start does
  2. Similar deal with volumes
  3. Updating a machine is almost like create, but it’s a bit simpler

The most resilient setup would be to precreate machines / mounts you think you’ll need, then leave them stopped until you want to use them.

The quickest thing to build would be something that provisions machines / volumes right when you need them, then issues fly-replay. I’d probably start with this and do some testing to see if you need to do more resilience work.

One thing to keep in mind is that there are limits on how many machines you can create. We can raise those, so if you think you’re going to go over 100 at any given time it’s best to send in a request for an increase.

6

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