10 hours ago
Hello Railway Team,
We are preparing a controlled SQLite-to-PostgreSQL production migration for our Python/Flask application hosted on Railway.
Our current production artifact was originally deployed using railway up.
During the migration, we need to activate maintenance, worker-suppression, and database-freeze environment variables. These variables are read at application startup, so applying them requires a new application process.
We performed one isolated qualification using railway redeploy. Although the source was unchanged, Railway generated different snapshot, source-image, and final container-image identities.
Our migration operator correctly rejected the redeployment because we could not prove that the approved container image remained unchanged.
We are considering Skipped Builds, but we understand that the feature is experimental and do not want to rely on undocumented assumptions.
Could you please clarify the following?
1. Compatibility with Railway CLI deployments
Can Skipped Builds reuse an existing container image originally built through railway up?
Are there any restrictions or prerequisites for CLI-uploaded deployments?
2. Variable-only deployment without rebuilding
What is the officially supported procedure for applying staged runtime environment-variable changes while reusing the exact existing container image?
Does this procedure work for a service originally deployed using the Railway CLI?
3. Authoritative OCI image digest
Is there a supported Railway API, CLI command, or deployment metadata field that exposes the actual OCI image digest used by the running deployment?
How can we verify that the pre-change and post-change deployments use the exact same immutable image?
4. Cache miss and rebuild prevention
If Skipped Builds cannot reuse the cached image, does Railway automatically start a new build?
Is there a supported way to prohibit fallback rebuilding and fail the deployment instead?
If not, how can an operator reliably detect a rebuild and reject the resulting deployment before relying on it for a database cutover?
5. Supported alternative
If Skipped Builds cannot guarantee these requirements for a CLI-uploaded artifact, does Railway support another approach, such as deploying an explicitly pinned immutable OCI image digest while changing only runtime variables?
We are specifically seeking a documented, auditable mechanism rather than a best-effort reuse of the same source code.
We do not intend to change our production configuration until these questions are clarified and the mechanism has passed an isolated qualification.
Thank you for your technical guidance.
3 Replies
Status changed to Awaiting Railway Response Railway • about 9 hours ago
Status changed to Solved misscapuchino • about 9 hours ago
9 hours ago
Hello Railway Team, I accidentally marked this thread as "Solved." My technical questions have not been answered yet. Could you please reopen this thread and keep it open until we receive clarification regarding Skipped Builds, CLI-uploaded artifacts, and immutable OCI image verification?
Thank you!
Status changed to Awaiting Railway Response Railway • about 9 hours ago
9 hours ago
The thread is open again. Here's what we can confirm so far.
Skipped Builds works by checking whether an image was already built from the same source code. If it finds one, it deploys that image and applies the current variables at runtime. Variable changes don't count as a source change. The feature is off by default and you turn it on per service under Feature Flags in Service Settings.
Three actions always trigger a full rebuild, even with Skipped Builds on: Redeploy from the Deployments tab, "Deploy Latest Commit", and railway up, which always uploads and builds your code. That matches what you saw with railway redeploy. Because every railway up creates a new build, we can't say Skipped Builds will reuse an image that came from a CLI upload.
The other supported source type is a Docker image, which you set from the service source setting or with railway service source connect --image. Deploying from a private registry requires the Pro plan. We can't yet confirm whether an image source accepts a digest-pinned reference, whether any API field or CLI command shows a deployment's OCI digest, or whether there's a setting that fails a deployment instead of rebuilding when no cached image exists. We don't want to give you assumptions on any of those three for a production cutover.
Status changed to Awaiting User Response brody • about 9 hours ago
brody
The thread is open again. Here's what we can confirm so far. [Skipped Builds](https://docs.railway.com/builds/skipped-builds) works by checking whether an image was already built from the same source code. If it finds one, it deploys that image and applies the current variables at runtime. Variable changes don't count as a source change. The feature is off by default and you turn it on per service under Feature Flags in Service Settings. Three actions always trigger a full rebuild, even with Skipped Builds on: Redeploy from the Deployments tab, "Deploy Latest Commit", and `railway up`, which always uploads and builds your code. That matches what you saw with `railway redeploy`. Because every `railway up` creates a new build, we can't say Skipped Builds will reuse an image that came from a CLI upload. The other supported source type is a Docker image, which you set from the service source setting or with `railway service source connect --image`. Deploying from a private registry requires the Pro plan. We can't yet confirm whether an image source accepts a digest-pinned reference, whether any API field or CLI command shows a deployment's OCI digest, or whether there's a setting that fails a deployment instead of rebuilding when no cached image exists. We don't want to give you assumptions on any of those three for a production cutover.
an hour ago
Thank you for the detailed clarification. This confirms why our previous P04 qualification correctly failed closed.
We understand that Skipped Builds cannot provide the required guarantee for our CLI-uploaded artifact.
Before we proceed with an isolated test using an external OCI registry, could you please escalate these remaining questions to the team responsible for Docker image deployment and provenance?
- Does Railway accept an immutable image reference in the form ghcr.io/org/image@sha256: as a service source?
- When runtime variables change, can Railway deploy from that exact immutable image without rebuilding or resolving a different image?
- Is there an authoritative Railway API, CLI field, or deployment metadata field exposing the OCI digest of the image actually deployed/running, so we can verify it against the approved digest?
If any capability is unsupported, please confirm that explicitly. We need a fail-closed, verifiable mechanism for a controlled database migration and do not want to rely on undocumented behavior.
No production changes will be made while these questions remain unresolved.
Thank you for your help.
Status changed to Awaiting Railway Response Railway • 44 minutes ago