a month ago
Hello Railway Support,
I am migrating services from Render to Railway using API-based service updates/deploys.
Most services migrate successfully, but two services consistently fail with Cloudflare 403 challenge responses from Railway API:
Kistie-Store
pc-checker-extreme
Behavior:
Same token/project can read services and deploy other services successfully.
These two services repeatedly fail at Railway API call stage with HTML response:
“Attention Required! | Cloudflare”
Retries from same environment always reproduce.
Project context:
Railway project id: 66657765-bf4e-4504-8b48-dc77c935e0d2
Environment id: 66657765-bf4e-4504-8b48-dc77c935e0d2 (from API workflow context)
Command used:
python manage.py transfer_render_to_railway --mode demand --redeploy-existing --verify-timeout 300 --verify-interval 10 --only Kistie-Store --only pc-checker-extreme
Recent timestamps (UTC):
2026-06-10, repeated attempts in current session
Both services fail with the same 403 Cloudflare gate
Request:
Please review/clear any Cloudflare/API edge block affecting these requests.
Please confirm if our source IP/account/project needs allowlisting.
Please advise any required headers/token scope changes for these endpoints.
1 Replies
Status changed to Awaiting Railway Response Railway • 27 days ago
a month ago
The 403 is Cloudflare's web application firewall flagging something in the request payload for those two services as malicious, not a token or account problem. Since other services deploy with the same token, the token scope is fine and there is nothing to allowlist on your IP, account, or project. We do not allowlist individual IPs or accounts at the edge, so the fix is on the payload side: identify what in the request for Kistie-Store and pc-checker-extreme is tripping the filter (often values that look like URLs, scripts, or IP addresses in variables) and adjust it. Practical options are to create the service first and set variables in smaller batches, split or base64-encode the values that look suspicious, or run the same operation through the Railway CLI, which often gets past the filter. Cloudflare does not tell us which part of a payload it blocked, so we cannot point to the exact field. We are tracking the underlying issue so legitimate requests like these are not caught going forward.
Status changed to Awaiting User Response Railway • 27 days ago
20 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 20 days ago