Hi Railway Support team,

I’m looking for guidance on securely using sealed variables in production. We’re trying to avoid plaintext secrets, but during production bootstrap we hit several failures that seem related to how sealed/reference vars are resolved.

### Context

- We created production by using Railway’s “Sync changes from staging” UI action.

- This cloned services/config from staging into production.

- We then updated production-specific vars and attempted to seal sensitive values (DATABASE_URL, MIGRATIONS_DATABASE_URL, storage keys, etc.).

### Failure modes we encountered

1. backend-api / backend-worker startup crash when DB vars were sealed:

- TypeError: Cannot read properties of undefined (reading 'searchParams')

- Stack pointed to pg-connection-string parse path.

- This looked like DATABASE_URL was undefined/empty at runtime.

2. Subsequent runs showed DB fallback behavior:

- ECONNREFUSED ::1:55432 and 127.0.0.1:55432

- This suggests app defaulted to local DB when env var did not resolve.

3. Redis resolution issue:

- getaddrinfo ENOTFOUND $

- We saw this when using templated/interpolated Redis URL values.

4. Practical pattern observed:

- Unsealed literal values often worked immediately.

- Equivalent sealed/reference-based values were inconsistent during bootstrap until we manually iterated vars/redeploys.

5. KEY QUESTION: do sealed shared variables work?

- This would be our preference

- But in most scenarios (database DSNs, redis addresses) it didn't work.

- Sealed shared variables did work with external API keys (example, our OpenAI provider key)

### What we need from you

Could you confirm the canonical and supported pattern for secret management in this setup, specifically:

1. Is it fully supported to use sealed vars whose value is a Railway reference, e.g.

DOCUMENT_INGESTION_STORAGE_ACCESS_KEY_ID=${{bucket.ACCESS_KEY_ID}}

MIGRATIONS_DATABASE_URL=postgresql://${{postgres.POSTGRES_USER}}:${{postgres.POSTGRES_PASSWORD}}@...

2. Are sealed refs resolved at deploy time or runtime?

Any known caveats during first deploys, especially right after “sync from staging”?

3. Are there known issues where sealed vars can appear empty/unresolved until re-saved/redeployed?

4. What is the recommended migration sequence to move from working unsealed vars to sealed vars without downtime?

5. Is there a safe way to validate the final resolved value (or at least resolution status) without exposing secrets?

6. Is there a way to make sealed shared variables work with redis urls and database DSNs, or is there another pattern that is both convenient and secure we should be using?

We now have the system mostly stable, but we want to lock everything down properly and avoid another regression. Any concrete guidance or checklist would be greatly appreciated.

Thank you! We love the platform otherwise. It's amazing.

Andrew