Sealed variables are designed to be write-only: once a variable is sealed, its value is provided to builds and deployments but isn't shown in the dashboard and can't be retrieved through the API, railway variables, or railway run. We have not verified how a staged, not-yet-committed sealed overwrite behaves when read back with decryptVariables:true, and staging sealed values through the API and reading the patch back is not a documented workflow.

The documented way to replace a sealed value is the edit option in the variable's 3-dot menu on the service's Variables tab; sealed variables can't be updated through the Raw Editor and can't be unsealed.

For production credentials, our guide to rotating credentials with zero downtime covers safe swaps, and using an external secrets manager keeps values outside Railway entirely. Sealing doesn't stop our own systems from decrypting a value, since that's how it reaches your container, so a value Railway must never be able to decrypt should be encrypted in your application first.

Thank you for the response.

I still need help because our controlled test demonstrated that a staged sealed-variable overwrite was readable through the pending-change API using patch(decryptVariables:true), even though we explicitly requested isSealed:true.

I understand that Variables → Edit is the documented replacement method.

Before using that method with production credentials, can a Railway engineer confirm:

1. Whether the Edit workflow prevents the pending plaintext readback we observed.
2. Whether an authenticated API client can retrieve the pending value before commit.
3. Whether there is a supported way to replace an existing sealed secret without exposing its plaintext through pending-change metadata.

We used only synthetic values and deleted the test resources.

We have a production application waiting on three credentials and need the safest supported procedure to restore service.

Please escalate this question to a technical specialist if necessary. Thank you.

We could not confirm how a staged sealed value behaves before it is committed, so we cannot say whether the Edit workflow avoids the readback you saw. That applies to edits from the dashboard as well: variable edits made there also go into a staged changeset before they are applied.

What our documentation does establish is that once a sealed variable has been committed, its value goes to builds and deployments but is never visible in the UI and cannot be retrieved through the API. Sealed variables are updated with the edit option in the variable's 3-dot menu, not through the Raw Editor.

For the three production credentials, committing each change right after you stage it keeps the pending window as short as possible. Our guide to rotating credentials with zero downtime covers how to swap them safely. If a value must never pass through Railway in plaintext, a value you encrypt in your application first or keep in an external secrets manager avoids that exposure.