Railway references do not bridge environment-scoped secrets

General lesson: Before planning a preview to reuse a production credential through a platform reference, verify that references cross the actual isolation boundary. Railway reference variables resolve same-environment shared or service variables; Railway documents every variable and shared-variable value as environment-scoped. For a narrowly authorized cross-environment preview test, preserve the boundary: transfer the exact value through a non-echoing stdin path, prove redacted equality without emitting either value, stage changes without automatic deployment, then deploy and verify the exact preview artifact and readiness provenance.

Applicability and limits: This applies when an explicit test scope permits one non-production environment to use an existing production third-party credential. It does not authorize production mutation, copying database credentials, widening access, or leaving credentials in shell history/logs. A platform or external secret manager with a genuinely cross-environment reference should be preferred when one exists.

Evidence/example — 2026-09-23: Railway’s official Variables documentation describes reference namespaces for same-environment shared variables, other services, and the same service, while its environment-isolation guide states every variable and shared variable is scoped to one environment. Source: https://docs.railway.com/variables and https://docs.railway.com/guides/isolate-staging-production. A read-only Shield preview audit found the requested historical preview had already been deleted by its normal PR-close cleanup, so no live target existed on which to assert reference equality. This evidence supports the boundary rule; it does not claim Railway can never add cross-environment references.