Prior to Feb 28 2026, I would issue a CLI secrets command where I set some environment variables within my Fly app and the machine would automatically start. Once the machines performed their task (sending a video restream via ffmeg), the machines would automatically stop. This has been working without an issue for at least 3 months when I first started using Fly. Now, when the CLI secrets command is sent, the machine does not start. The logs show the following: “Pulling container image registry.fly.io/sctv-facebook-restream-church3562@sha256:c…
15:52:09
Container image registry.fly.io/sctv-facebook-restream-church3562@sha256:c…. already prepared
15:52:10
Configuring firecracker
15:52:11
machine was in a non-started state prior to the update so leaving the new version stopped”.
Since it no longer worked properly, I attempted to start the machine using the CLI, but when running the start command, I get “Waiting on lease for machine …” and it eventually fails.
How can I fix this so that the machine starts properly like it has prior to this mysterious “update”? Any help would be greatly appreciated.
Hi… fly m leases clear usually works for me in this kind of situation.
Regarding the question of why it didn’t start on its own, that’s the intended behavior in many configurations. Machines with auto-scaling enabled stay stopped after a deploy, in particular. (Not everyone agrees that this a good policy, though.)
If you post your full fly.toml, people here in the community forum might be able to give more advice.
Hope this helps!
here’s my fly.toml:
app = ‘sctv-facebook-restream-church3562’
primary_region = ‘dfw’
kill_signal = “SIGTERM”
kill_timeout = “30s”
[build]
dockerfile = ‘Dockerfile’
[[vm]]
memory = ‘512mb’
cpu_kind = ‘shared’
cpus = 1
As I mentioned, this has been working almost daily for the past 3 months. No changes on my end. All of my servers (over 25) stopped working on Feb 28th. Any help would be appreciated.
Hm… Do they start successfully if you clear the leases manually? (And then fly m start?)
Also, it might help to know which version of flyctl you are using…
flyctl version 0.4.16
As far as I know, a redeploy should have started those Machines (since they don’t have auto-scaling configured). That’s how things worked the last time I experimented with it, around 3 weeks ago. Stopped Machines without [[services]] were transitioned to started.
| with auto-scaling |
without auto-scaling |
||
|---|---|---|---|
started |
→ | started |
started |
stopped |
→ | stopped |
started |
suspended |
→ | stopped* |
started |
*Not suspended.
This might be a change in the Fly.io platform infrastructure that got out of synch with flyctl, although I don’t see any commits pending in the latter’s public GitHub repository.
If you could provide more complete information, then that would improve the odds of someone from Fly.io noticing here in the community forum. Or, if you have a Support plan with them, then just use their formal support portal.
Either way, I’d suggest not relying on any particular Machine-starting policy. This kind of thing isn’t really that stable, in terms of preserving past behavior. If the correct functioning of your app requires all Machines to be running after a new secret is set, then explicitly start them all, as a separate command, right before fly secrets set…
Tip: when showing code/config here, use Markdown block formatting if you can; the monospacing makes it easier to read.
As a small update… There is a patch that appeared subsequently, in v0.4.17:
https://github.com/superfly/flyctl/pull/4754
(I’m not sure whether that was trying to restore OP’s desired Machine-starting behavior, exactly, but it looks like it should at least avoid the part about lease conflicts…)
Thanks! - I will give this a try.