How to only have one machine running at once?

[vicontiveros00]

Having this problem where I’m having two machines running the same application simultaneously. I though the idea behind V2 is that only one is running and the other is on stand-by but they’re both running all the time. This is causing problems in my app (a Discord bot, where it responds twice to the same command because he’s running in 2 machines) how can I have only a single machine running or have one on stand-by? Here’s my fly.toml:

app = "eeroai"
primary_region = "arn"

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0

[ignoramous]

@vicontiveros00

though the idea behind V2 is that only one is running and the other is on stand-by

Stand-by machines are only implemented for processes in AppsV2 that do not have a [[services]] section defined: Increasing Apps V2 availability

@vicontiveros00

they’re both running all the time.

This is a known problem (?) for non-HTTP apps (?). In our case, multiple machines (same region) serve TCP connections despite the aggregate connection count being within soft_limit.

@vicontiveros00

This is causing problems in my app (a Discord bot, where it responds twice to the same command because he’s running in 2 machines)

Sounds like you need a queue, or an orchestrator like temporal.io / apache airflow?

@vicontiveros00

how can I have only a single machine running or have one on stand-by?

The crudest way is to provision just a single machine per app.

[vicontiveros00]

Is there something wrong with my config that causes both machines to spin up? How could I provision a single machine?

[ignoramous]

@vicontiveros00

How could I provision a single machine?

fly m destroy <machine-id> -a <app-name> one of the two provisioned machines. Exercise caution as a machine once removed isn’t going to come back.

Understand that two machines are better than one. Rather than removing a machine, I’d wager one is better of using an orchestrator like Temporal and/or using SQS or Cloudflare Queues as event sources, assuming async processing is okay in this scenario.

@vicontiveros00

there something wrong with my config that causes both machines to spin up?

Don’t think so. Something might be up with Fly but I can’t say for sure. I see a similar behaviour in my app, too.

[containerops]

@ignoramous

Understand that two machines are better than one. Rather than removing a machine, I’d wager one is better of using an orchestrator like Temporal and/or using SQS or Cloudflare Queues as event sources, assuming async processing is okay in this scenario.

+1 Yeah, this was one of the patterns I remember seeing a few years ago in the Discord bot community. It was also the only way to roll out new features without having to go offline and reconnect to the Gateway. For example, a gateway instance that queues messages in rabbitmq + some app instances to handle commands.

[andie]

@vicontiveros00

Is there something wrong with my config that causes both machines to spin up? How could I provision a single machine?

Hi @vicontiveros00
We do deploy 2 Machines for every process with services (unless there’s a volume mounted), for redundancy. But while 2 Machines is usually better, there are cases where users only want 1 Machine. As already mentioned, you can destroy one of the Machines. Then, when you deploy again, use the --ha flag to turn off the redundancy feature:

fly deploy --ha=false