We checked our documentation and it does not cover this yet, so the Railway community is the best place to get a real answer: people who have already worked this out on their own projects and can tell you what actually worked.

So we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who answers it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.

Opening this publicly is fine. For audit purposes, however, I specifically need an authoritative confirmation from a Railway staff member or engineer about the provenance and semantics of Deployment.meta.imageDigest.

A community workaround or empirical observation would be helpful, but it would not be sufficient to close the immutable-artifact audit requirement.

Could a Railway team member please confirm whether this field is independently recorded from the registry manifest actually resolved and pulled for the specific deployment, rather than copied from the configured image reference?

Deployment.meta.imageDigest is populated from image metadata reported by the container runtime after container creation and saved when the deployment succeeds. It isn’t simply copied from the configured image reference.

However, it doesn’t independently prove that a fresh authenticated registry pull occurred for that deployment. Images pinned by digest can be reused from the host’s local cache.

This describes the current implementation. We can’t confirm a documented, stable audit guarantee for this field, so it shouldn’t be used alone as proof of independent pull provenance.

We’ll leave this open for the community to help with any further questions about verification approaches and audit workflows.

Thank you — this clearly answers the current semantics of Deployment.meta.imageDigest.

A fresh registry pull is not itself required for our audit; reuse of a content-addressed image from the host cache is acceptable. What we need to attest is the immutable image digest actually used by the runtime to create the container for that deployment.

Does Railway expose any documented and supported API field, deployment record, attestation, or other mechanism that can be used to verify that runtime image identity for audit purposes?

If no such supported mechanism currently exists, could you please confirm that explicitly?

Hello Railway Support,

We reviewed the existing digest-pinning thread (https://station.railway.com/questions/docker-image-digest-pinning-across-envir-b7bc22aa) and runtime digest-verification thread (https://station.railway.com/questions/docker-image-digest-verification-48f24782). The moderator confirms dashboard digest pinning; the employee describes runtime-derived Deployment.meta.imageDigest but explicitly does not guarantee stable audit semantics. We are not asking for proof of a fresh registry pull; reuse of a verified content-addressed cache is acceptable.

For Railway Pro, can you identify a documented, supported read-only mechanism that:

1. Confirms that a private ghcr.io/OWNER/IMAGE@sha256:DIGEST source is honored without tag resolution or rebuilding, including variable-only redeploys with image auto-updates disabled?
2. Returns the image digest actually used to create the running container, rather than merely the configured reference, bound to project, service, environment and deployment IDs? Please distinguish an OCI index digest, selected linux/amd64 manifest digest and image config digest, including multiple replicas.
3. Allows an independent authenticated reread of that binding and defines freshness, replacement/restart behavior and retention/expiry for the record and image, including rollback?

Please provide the supported field/endpoint and its documented semantics, or confirm which of these guarantees is unavailable. An example sanitized response is sufficient. This is an information request only: please do not deploy, change configuration or access application/member data.

Thank you.