flyctl deploy does not honour all entries in config for machine apps

[ignoramous]

I recently deployed udns, a Machine app, with flyctl to all available Fly regions, and found that, one VM is spun-up per connection instead of the connection being sent to an already alive VM.

The Machine app’s services section contains:

[[services]]
internal_port = 8080
protocol = "tcp"

  [services.concurrency]
  hard_limit = 75
  soft_limit = 60
  type = "connections"

But when I fetch config for the app, it shows:

$ fly config display -a udns
...
    "services": [
        {
            "concurrency": {
                "hard_limit": 25,
                "soft_limit": 20,
                "type": "connections"
            },
...

Though, it behaves as if hard_limit was set to 1.

Besides, I notice that kill_timeout and services.tcp_checks sections are also different from what’s defined in my Machine app’s toml that I flyctl deploy -c deployed with.

[eli]

fly config definitely has some rough edges. As you’ve probably noticed, the limits you’re getting in fly config getting are the defaults. I’d imagine you might have a better time using the API to create/update machines for now,

The fly machines subcommands all are fine to use, but things like fly config or fly secrets set aren’t the most stable yet. Of course, we are aiming to someday have flyctl be fully compatible with machines apps!

[ignoramous]

@eli

I’d imagine you might have a better time using the API to create/update machines for now,

Yikes, no. I like my flyctl. I’ll patiently wait in the bushes for it to mature.

What led me astray was, the preview announcement on the forum mentioned that flyctl deploy -c would work like one would expect it to…

@eli

Of course, we are aiming to someday have flyctl be fully compatible with machines apps!

Any timelines?