Usually ran as a separate Fly app (a shared-1x cpu with 256mb mem should be enough is my guess) on a forked repo. Typically, you’d keep main unchanged and in-sync with upstream, and merge that main into your own branch with changes specific to your app carried forward, forever.
Or, you can instruct fly deploy to ignore values in fly.toml by supplying either a different my.fly.toml with the --config switch, or by supplying args against --env, --app etc to fly deploy itself.
There are multiple ways to set env vars for a Fly app. As an example, fly secrets set ... is one (abusive) way to set env for an app. ENVs set in Dockerfiles also carried in to your app’s vm. As mentioned above, yet another way is to pass env with the fly deploy -e k1=v1 -e k2=v2 ... switch (doing so, makes fly deploy ignore the [env] section in fly.toml, entirely).