19 days ago
Service Details
- Project: [retracted] (ID: 73fb76b9-3999-4b20-ae6f-c2adb02069c1)
- Environment: staging (ID: d287b9a1-54be-49e0-aab5-a8a762939f30)
- Affected Service: imgproxy (ID: 2cba1ab3-3c69-4b35-a158-955228d382a9)
- Consuming Service: frontend (ID: 034789b1-1290-42ef-a0c9-b71e033efb4d)
Problem
Changed imgproxy's custom domain from auto-generated imgproxy-staging-fc6f.up.railway.app to [retracted]-staging-cdn.up.railway.app
The custom domain works correctly—accessing [retracted]-staging-cdn.up.railway.app successfully routes to imgproxy
BUT the environment variable reference ${{imgproxy.RAILWAY_PUBLIC_DOMAIN}} still resolves to the old domain (imgproxy-staging-fc6f.up.railway.app)
Services redeploying after the domain change still receive the old domain value when using the reference
The imgproxy deployment tab also shows the old domain
Expected Behavior
${{imgproxy.RAILWAY_PUBLIC_DOMAIN}} should resolve to the new custom domain [retracted]-staging-cdn.up.railway.app
Actual Behavior
Reference resolves to stale value: imgproxy-staging-fc6f.up.railway.app
Impact
Frontend service cannot use the reference to get the correct imgproxy domain, forcing hardcoding as a workaround.
1 Replies
19 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 19 days ago
19 days ago
Your reference syntax looks correct. Railway documents RAILWAY_PUBLIC_DOMAIN as the public service/customer domain, so if the new custom domain is verified and railway domain list --service imgproxy --environment staging --json shows it, but a fresh deployment still injects the previous *.up.railway.app value into ${{imgproxy.RAILWAY_PUBLIC_DOMAIN}}, this points to stale system-variable resolution rather than DNS or the frontend reference syntax.
As a safe workaround, define an explicit non-system variable such as IMGPROXY_PUBLIC_DOMAIN=<current custom domain> and reference ${{imgproxy.IMGPROXY_PUBLIC_DOMAIN}} from the frontend. This is manual if the domain changes again, but it avoids relying on stale injected system metadata.
For Railway to investigate, share the affected imgproxy and frontend deployment IDs together with sanitized output from the domain-list command and the resolved value (please do not include secrets). The fact that both the deployment tab and a newly-created deployment show the old domain would be strong evidence that the platform's domain-to-runtime-variable mapping is stale.