21 days ago
Hi — we're migrating from railway.toml to .railway/railway.ts ahead of the December cutoff (project "Clad Dashboard") and hit a blocker.
We manage secrets in Doppler, synced to Railway. IaC treats any variable not named in the authoring file as a deletion (our first railway config plan proposed hundreds of deletions because these were not specified). IMO, the migrate-generated preserve() lists don't solve this long-term, as you have to track every single env variable change in IaC, which feels somewhat error prone and tedious.
I think a good solution could be a first-class way to say "this service's variables are not managed by IaC". For instance, leaving env blank doesn't indicate that there are not env variables. Seems like there's precedent in the engine already (e.g.- a database node with no networking block keeps its live exposure rather than reading as a deletion). Could also do a variables: unmanaged marker or a wildcard preserve().
Also let me know if I'm thinking about this in the wrong way or missing something!
3 Replies
Status changed to Awaiting Railway Response Railway • 21 days ago
21 days ago
There is no unmanaged escape hatch today, and omitting the env block does not create one. The planner skips variable diffing only when the service has no variables on Railway either, so for a service that already has Doppler-synced variables an omitted env block reads as an empty desired set and every live variable comes back as a delete. The networking behavior you spotted is real, but it is a database-specific rule and nothing equivalent exists for variables.
preserve() per variable is the only mechanism right now. Since the config file is real TypeScript and defineRailway accepts an async function, you can generate that list instead of hand-tracking it, for example pulling the key names from Doppler at plan time and spreading Object.fromEntries(keys.map(k => [k, preserve()])) into env. Values stay out of source and the plan stays clean without enumerating anything manually.
Status changed to Awaiting User Response Railway • 21 days ago
21 days ago
got it, and no plans to change this before the deadline?
Status changed to Awaiting Railway Response Railway • 21 days ago
21 days ago
There is no committed work for an unmanaged marker or wildcard preserve() ahead of the December cutoff. The generated-preserve() approach from the previous reply is the recommended path for Doppler-synced services.
Status changed to Awaiting User Response Railway • 21 days ago
14 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 14 days ago