flyctl deploy doesn't deploy fly.toml. [env] args not showing

[ssull]

Last night I updated my fly.toml to edit a env variable and did a flyctl deploy. Once deployed, my machines crashed and I noticed the fly configuration in the web GUI didn’t match what was supposed to be deployed; specifically, it didn’t have any of my env variables. Tried a few different things last night (flyctl config validate, rebuilt the config file, tried flyctl build -c fly.toml, etc) to no avail.

Was able to get things working again this morning by building my env variables in the command line itself (ex: flyctl build –env FOO=BAR). This is fine as a work around, but it still doesn’t use the toml file itself.

Any thoughts? Thanks!

Context:

flyctl version 0.4.57

Screenshot shows my config in the web gui when in the broken state (note: none of my additional env vars present).

My fly.toml file:

app = 'APPNAME'
primary_region = 'ord'

[build]
  [build.args]
    GO_VERSION = '1.24.2'

[env]
  SYNC_CADENCE = "15m"  
  LOOKBACK     = "6h"   
  FILTER       = "TEST" 


[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = "off"
  auto_start_machines = true
  min_machines_running = 0
  processes = ['app']

[[vm]]
  memory = '1gb'
  cpu_kind = 'shared'
  cpus = 1

[lubien]

Hey there. Sorry that this happened.

The current state of fly.toml is defined based on the latest release and thats what’s shown in the UI. What might have happened is that something/someone deployed a previous version after your local fly deploy.

My suggestion is to look at your Activity page on your app to see what/who deployed when

[ssull]

This is a personal project, so it’s me all the way down. Here’s a screenshot showing from last known good into yesterday’s failure.

[lubien]

Interesting. Can you mail me lubien at (our domain) with your app name so I can investigate a bit?

[ssull]

Sent!

[lubien]

Just got it. It was marked as spam so thanks for replying here too otherwise I might have missed it

[lubien]

Oh I have more info. Here’s the timeline

• Release v81 had the correct envs even tho it failed
• Release v82 to 84 had only PORT env
• Around 2026-06-02 23:21:48.956716678 there was a UI deployment to deploy secrets but I believe it did not create a release
• Release v85 (create by UI by “deploy secrets”

My advice would be to track down what happened that made your deploys from v82 to v84 not have the envs in your toml. Maybe a git stash? Maybe switching branchs and deploying? CI?

Running fly deploy will always look for the config file which is by default fly.toml unless you pass -c path/to/file.toml.

[ssull]

Hey,

Nothing could have happened to my file. I use source control (git), but no CI/CD. This is just a small personal project and I do all the deployments manually from my laptop.

Yesterday I updated one env var (the only change made), deployed it, and had my issue. After the issue I destroyed my machines, tried to do the secrets deployment you called out (it failed, due to me not adding a new machine). Once I added a machine back, the secrets deployed, but I had the same issue. I tried redeploying an update yaml in a few different ways (including using -c path/to/file.toml) and nothing working until I passed the env vars directly like I showed in my original message.

I retried a deploy this afternoon, and it was successful this time. Not sure what the issue was, but we can go ahead and close this request.

Thank you for helping troubleshoot with me.

[lubien]

Before we close I think there’s interesting info here:

After the issue I destroyed my machines, tried to do the secrets deployment you called out (it failed, due to me not adding a new machine)

If, somehow, the fly.toml was not there I recall flyctl try to create one from machines but as there were no machines flyctl might have created a blank one without envs.

---

But I agree, we can close this one if thats okay