2 hours ago
Hello Railway team,
I need clarification of supported deployment/API behavior for a source-built PostgreSQL service on Hobby. This is a platform contract question; no account access or project changes are requested.
The verification flow requires two distinct deployments with exactly the same retained image digest and source index, but different public runtime verification payloads and an explicitly reviewed start command. A rebuild of the same Git commit is insufficient. The image selection must be established before a volume verification record is written.
-
For deploymentRedeploy(id, usePreviousImageTag: true), are custom variables and startCommand taken from the referenced deployment, the current service configuration, or another snapshot? Is that selection a supported API contract?
-
Is there a supported operation to create a new deployment from a specified retained image digest with updated runtime variables and startCommand, failing before container start if that exact image is unavailable, without silently rebuilding or selecting another cached image? If so, which operation and parameters should be used?
-
If Skipped Builds is the supported route, which trigger applies current runtime variables and startCommand, and is there any way to require the exact expected cached image rather than a best-effort cache hit? The documentation explains new runtime variables but does not establish these digest/start-command guarantees.
I have checked the current Deployment Actions and Skipped Builds documentation and the official CLI v5.70.0 schema. Please confirm whether a deterministic supported path exists; if it does not, an explicit confirmation of that limitation is helpful.
Thank you.
1 Replies
2 hours ago
With deploymentRedeploy(id, usePreviousImageTag: true), the new deployment reuses the image from the referenced deployment, and service variables are resolved from the service's current configuration at deploy time. The start command follows the referenced deployment's configuration rather than any later dashboard edits, so a redeploy is not a way to pair that image with a newly reviewed start command. We don't publish this selection behavior as a guaranteed API contract.
There isn't currently an operation that creates a deployment from a specified image digest together with updated variables and start command. If a previous image is no longer available, the redeploy fails when the container is started instead of falling back to a rebuild, but you can't give us an expected digest to check against beforehand.
Skipped Builds is a best-effort cache. It doesn't let you require one exact cached image or reject a cache hit on a different image.
In short, we don't currently offer a deterministic supported path that guarantees the same image digest and also applies a newly reviewed start command and runtime variables.
Status changed to Awaiting User Response Railway • about 2 hours ago