23 days ago
Agents and automation currently cannot distinguish between a missing variable and a sealed variable that exists but is hidden. This leads to false reports that required secrets are missing.
It would be helpful if the CLI exposed presence metadata for sealed variables, without revealing the value. For example: variable name, scope, and status such as present/sealed. This would let agents and scripts validate configuration safely without needing access to secret values.
If some users prefer sealed variables to remain completely invisible to the CLI, this could be controlled by a per-variable visibility setting. That would allow sensitive variables to stay hidden while still letting teams expose presence-only metadata for automation and deployment checks.
0 Threads mention this feature
1 Replies
23 days ago
Since the UI is not letting me submit another feedback thread with similar, but not equivalent scope:
Add a safe names-only mode for CLI variables
The Railway CLI currently lists variable values by default. For agents and automation, this makes it hard to verify whether required variables exist without risking secret exposure.
Filtering railway variable list --json through tools like jq can hide values after the fact, but the CLI process has already received the full secret values. That is not a reliable safety boundary.
It would be helpful to add a names-only or metadata-only mode, for example:
railway variable list --names
railway variable list --metadata
This mode would return variable names, scope, and presence status without returning values. If users need the current behavior, it could remain available through an explicit flag such as --include-values or --reveal-values.
The main use case is deployment/configuration validation. Agents and scripts often need to answer questions like “is XYZ_API_KEY configured for this service?” or “does this environment have the required S3 credentials?” They do not need the secret values to answer those questions.
This is still useful even when sealed variables exist. A secret may have been newly added and not sealed yet, a workspace may not have sealed-variable rules fully applied, or an operator/agent may simply choose the wrong inspection command during debugging. A names-only mode gives automation a safe default path and reduces the chance that a routine config check turns into secret exposure and key rotation.