Clarification on Image Auto-Updates latency and programmatic redeploy via GraphQL API

gaboldev

PROOP

13 hours ago

Hi Railway Team,

We are planning our production CI/CD strategy using immutable Docker images stored in GHCR and pushed to Railway via Image Auto-Updates. Before finalizing our setup, we'd like to clarify two points:

What is the maximum expected latency or polling interval for Railway to detect a tag update in an external registry and automatically trigger a deployment?

Is there a public GraphQL API mutation available that allows us to programmatically trigger an immediate redeploy (force-pulling the latest image tag) directly from our CI/CD pipeline to bypass polling wait times?

Thanks!

$20 Bounty

2 Replies

Railway

BOT

13 hours ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • about 13 hours ago

mayori

MODERATOR

9 hours ago

There is no fixed maximum delay for Image Update Detection

Yes, There is public API available to trigger new deployment, You can call the mutation environmentTriggersDeploy to trigger new deployment for the specific service

https://docs.railway.com/integrations/api/manage-deployments#deploy-a-specific-service-in-an-environment

codeverselabs

FREE

6 hours ago

Railway doesn’t provide a fixed maximum polling interval; detection can be delayed because registry results are cached for up to a few hours.

https://docs.railway.com/deployments/image-auto-updates

For production CI/CD, the better approach is to trigger a redeploy directly after pushing to the GHCR image.

Railway's public GraphQL API supports redeploying a service, so you don't need to wait for auto update polling.

https://docs.railway.com/integrations/api/manage-deployments

For your own application image, Railway actually recommends CI-triggered redeploy for an immediate, deterministic deployment.

https://docs.railway.com/guides/private-container-registry

Welcome!