2 hours ago
We deploy a fixed source tree using Railway CLI (railway up) and want to verify the relationship between the uploaded source, the build output, and the final deployed image without changing deployment methods. In a PREPROD rehearsal, the build export descriptor identified an OCI image manifest, while deployment metadata reported a different image digest. We restored the previous image as a precaution; this difference alone does not establish a platform error, and no production outage is being reported.
The AI assistant recommended asking Railway because the metadata and build logs we inspected did not expose enough information to verify the relationship. We would like guidance on supported product capabilities, rather than a rebuild or a resource change.
- For CLI source uploads, is there a supported way to export the fetched source snapshot or a per-file content hash inventory, bound to the corresponding upload/build/deployment?
- How can a customer retrieve the final deployed image manifest/index and verify its relationship to the build-export manifest when their digests differ? Is there a documented read-only registry/export or provenance API?
- If those exports are unavailable, what source-to-build-to-runtime identity checks does Railway support for this existing CLI workflow? Please distinguish deployment variable snapshots from source-content snapshots.
This is a general platform-capability question. Project identifiers, deployment identifiers, exact digests, logs, source contents, and credentials have intentionally been omitted from this public draft. If case-specific records are needed, please advise on an appropriate private channel available to a Hobby customer. No build, deployment, configuration change, or database operation is requested.
Prepared with Railway's support template (v1).
1 Replies
2 hours ago
We don't provide an export of the fetched source snapshot, a per-file hash inventory, the build context, or the built image manifest/index for railway up deployments, and there is no read-only registry or provenance API for pulling those artifacts.
For this CLI workflow, the identity checks available to you are the deployment records themselves (railway deployment list --json gives deployment IDs, statuses and timestamps you can bind to each railway up) and the running container. You can open a shell on the live deployment with railway ssh (or railway ssh -- <command>) and hash the files actually present at runtime, then compare that inventory against the hash list you generate locally from the fixed source tree before upload. Copying files off with scp/sftp through Railway SSH works for the same purpose.
On the distinction you raised: deployment variables are configuration attached to the deployment and are separate from the uploaded source content, so a variable comparison between deployments says nothing about which source files were built.
We have not determined why the build output and deployment metadata showed different digests in your rehearsal, so we can't confirm or rule out a specific relationship between them.
Status changed to Awaiting User Response Railway • about 2 hours ago