flyctl secrets list keeps showing all secrets as Staged despite deploys

Questions / Help
,
1

Hi,

I am seeing a weird secrets status issue on a Fly Machines app where the runtime
environment looks correct, but flyctl secrets list keeps reporting every
secret as Staged.

Environment:

  • Fly Machines app
  • flyctl v0.4.51 linux/amd64, BuildDate 2026-05-12T15:53:23Z
  • app has 8 Machines across app/worker process groups
  • UTC window around 2026-05-13 21:37-21:59+

The command:

flyctl secrets list -a <app> --json \
  | jq -r 'group_by(.status)[] | "\(.[0].status): \(length)"'

keeps returning:

Staged: 55

The confusing part is that the running Machines appear to have the correct
runtime environment.

Things I tried that did not clear the staged status:

flyctl secrets deploy -a  flyctl secrets sync -a  flyctl secrets sync
-a  && flyctl secrets deploy -a

I also tried importing current runtime values as non-staged secrets, setting one
targeted non-staged secret to its current runtime value, and doing a normal
current-image app deploy through our repo wrapper / flyctl deploy using the
current image and config.

For example, the targeted set was:

flyctl secrets set SENTRY_ENABLE_LOGS= -a

Deploys/releases did happen; the Machines were updated and became healthy each
time.

I found a few possibly related threads:

So I am wondering if this is just stale secret version/status metadata rather
than a real runtime secrets problem.

Can secret version/status metadata get stuck for a Machines app? If so, is there
any operator-side way to reset/reconcile the app-level minimum secret version or
status state?

Is this a bug on fly’s end?

I can share the app name / Machine IDs privately with Fly staff if useful.

Thanks!

2

Hi there,

Usually the secret state will be reset with a combination of flyctl secrets sync, followed by flyctl deploy. These steps would need to happen from the same machine, so for example, flyctl secrets sync on one machine, and flyctl deploy on another wouldn’t be likely to work — I’m not sure if your deploy on a repo wrapper happened on the same machine. If not, could you give that a try?

3

Hi,

I am also having a related issue. I have tried flyctl secrets sync and flyctl deploy - alongside using the frontend UI on the website multiple times.

No matter what I cannot get my secrets to update to the latest version - and it holds onto a previous version of the secrets.

I can tell that they are not being updated as one of my secrets is for a callback URL - the old URL is staying no matter how many times I deploy.

I first experienced this a few days ago, and just tried again now to see if it was a temp issue - and it is still a problem.

All my secrets are marked as deployed when using fly secrets list - but I doesn’t seem like they are updating at all. At least the secret being used for the callback is not updating. On the website UI they are marked as undeployed and pending.

Am I missing something?

4

Hi Devin1!

If you had initially set them on the Web UI, you’ll want to make sure to click the “Deploy Secrets” in the Web UI.

If they still don’t seem to be updating after that, try running fly secrets sync followed by fly secrets set KEY=“VALUE” KEY=“VALUE” for all of the key/value pairs you want to set as secrets, and finally fly deploy.

I hope that helps!

5

Thanks. Update from our side: we tried both paths now.

First, from the same deploy host, we ran:

flyctl secrets sync -a <app>

Then immediately redeployed the current production image for all process groups / all Machines. The deploys completed successfully, all Machines were started, checks were passing, and app health verification passed.

But:

flyctl secrets list -a <app> --json \
  | jq -r 'group_by(.status)[] | "\(.[0].status): \(length)"'

still returned:

Staged: 55

So this was not caused by running sync and deploy from different machines, or by only some Machines being redeployed.

Then we tried the follow-up suggestion, but scoped to one existing key instead of rewriting all secrets. We ran sync, then set one existing key to its current runtime value, without changing the value:

flyctl secrets set <KEY>=<current-runtime-value> -a <app>

That created a new release, updated all Machines, and cleared the status:

Deployed: 55

All Machines are now started/checks passing, and health verification passes.

One clarification: the original deploy path was working behaviorally for us. The Machines did appear to have the expected runtime environment after deploys. The issue was specifically that flyctl secrets list continued reporting the secrets as Staged even though the behavior/runtime state appeared deployed.

So it looks like a non-staged secrets set refreshed/advanced the app secret status metadata for the whole app, while sync + full deploy alone did not. Is that expected behavior?