an hour ago
Hello Railway Support,
We are reviewing an existing production Express API before enabling a privacy-sensitive event inquiry workflow.
This is a read-only technical inquiry. No deployment or configuration changes are requested.
1. Trusted client identity
Our Express API requires a trustworthy client-origin mechanism for public rate limiting.
We understand that Railway's public edge overwrites X-Real-IP and X-Forwarded-For.
- Is this consistent across custom domains, HTTP/1.1 and HTTP/2?
- How are duplicate or comma-separated values handled?
- What happens to the Forwarded header?
- Can private-network or other traffic reach the listener without public-edge sanitization?
- Is there a supported method to distinguish trusted public-edge traffic from private or unsanitized traffic?
- What mechanism do you recommend for identifying clients without trusting user-supplied headers or relying on assumed proxy hop counts?
2. Logs, retention and forwarding
- What plan and log retention period effectively apply to this workspace?
- Does the retention period represent log visibility or actual deletion, including internal copies?
- Is any platform-level forwarding enabled, and how can we verify its status?
- Which roles may view or export logs?
We do not need raw logs, IP addresses or personal data.
3. Deployment recovery
The currently active deployment is marked SUCCESS and our read-only integration reports canRollback=true and a snapshot reference.
- What guarantees apply to the availability of the rollback image and its expiration?
- Does rollback restore the associated environment-variable snapshot?
- How can we verify the exact recovery target before any live change?
- What is the supported recovery procedure after an older deployment image expires?
Please distinguish general documentation from verified project-specific details.
We are not asking for application-code debugging.
Please do not execute rollback, redeploy, change settings, modify networking or retrieve credentials.
Thank you.
1 Replies
an hour ago
Verified for your workspace: it is on Hobby with one member, you, as Admin. Everything else here is general platform behavior.
Our HTTP edge replaces any caller-supplied X-Real-IP, X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host on every public domain, custom or Railway-generated, rather than appending to them, and forwards HTTP/1.1 to your app, converting HTTP/2. We make no guarantee about how the Forwarded header is handled, so don't rely on it. Private-network traffic from services in the same environment, and HTTP sent through a TCP proxy, bypass that sanitization and can carry any headers. There is no edge-only ingress switch or signed edge header, and proxy source ranges are not a stable contract. For public rate limiting, key on X-Real-IP and treat every other path to the listener as untrusted.
Hobby log retention is 7 days. That is how far back you can view logs, not when they are deleted: every log is kept for 90 days and then removed, and no log can be deleted earlier. There is no log drain setting, so nothing forwards your logs off the platform unless you run a forwarder yourself.
Rollback restores both the image and the variables. Once a deployment is removed, its image is kept for 72 hours on Hobby. After that the rollback option disappears and Redeploy rebuilds from the original source with the original variables. Before any change, the deployment list shows each deployment, and Rollback is only offered on deployments still within retention. See rollback and image retention.
Status changed to Awaiting User Response Railway • about 1 hour ago