Make sure you have deployed the staged changes after editing your variables

variables dont disappear on their own - the fact that they get deleted and its always the same one surviving means something with api access is rewriting the variable collection. railways variableCollectionUpsert with replace wipes every var you dont include in the call, so if you have a ci step or script that "syncs" env vars and its payload only has SUPABASE_SERVICE_KEY, it deletes the rest on every deploy. staging survives because whatever syncs staging has the full list (or nothing syncs it).

how to confirm: open the project activity feed in the dashboard and look at what happens right after you add DATABASE_URL - you should see a variable change event from a token/integration, not a person. also check any deploy workflow, github action, or infra script for a railway api call or railway variables --set.

fix is either include all vars in that sync payload or drop the replace behavior. adding vars by hand will keep losing this race until the writer is stopped

Hey — I was able to reproduce your error: PrismaClientInitializationError: error: Environment variable not found: DATABASE_URL

manuproject's diagnosis above is spot on. To put it plainly: something with API access is calling variableCollectionUpsert with replace semantics, and that deletes every variable left out of the payload. So do the checks posted above.

• Checking the activity feed. Find the variable-change event just after you last added DATABASE_URL. It names the actor, so a token or integration rather than your own account confirms it.

• Auditing the deploy pipeline. One thing that narrows this down a lot: replace defaults to false. I tested the same partial payload with the flag left off and nothing was deleted. So ordinary API writes and plain railway variables --set calls aren't suspects — you are looking for one call that passes replace: true specifically.

  Search your pipeline for replace alongside variableCollectionUpsert — GitHub Actions workflows, deploy scripts, Terraform or Pulumi, any internal config-sync tool.

• Fix the payload, not the flag. Once you find the call, two options:

  1. Keep replace: true and send your complete variable set. If the script passes replace on purpose to prune keys deleted upstream, keep it — just make the payload complete.
  2. Otherwise drop replace and let the default merge apply.

Then re-add the missing variables and redeploy.

Hope this post clarifies the issue, appreciate manuproject for scoping this in. Looking forward to updates on your issue, hopefully a confirmation on the fix :)