Incident Report: March 30th, 2026 — Authenticated user data cached

Railway experienced an incident where CDN features were accidentally enabled for some domains without users enabling them.

For

For those affected, this may have resulted in potentially authenticated data being served to unauthenticated users.

On March 30, 2026 between 10:42 UTC and 11:34 UTC (52 minutes), a configuration change to our CDN caused HTTP GET responses to be incorrectly cached across ~0.05% of domains on Railway with CDN disabled.

During this window, cached responses may have been served to users other than the original requester.

On March 30, 2026:

• 10:42 UTC - A configuration update was deployed to our CDN provider. This accidentally enabled caching for domains that had CDN turned off.
• 11:34 UTC - The issue was identified. The change was reverted and all cached assets were purged globally.

The full incident is available on our Status Page here.

A CDN (Content Delivery Network) caches your application's content at edge servers around the world so it can be served faster to users. On Railway, CDN caching is opt-in. Domains without CDN enabled will always route requests directly to your application.

During this incident, a configuration update accidentally enabled caching on domains that had it disabled. As a result, responses — including authenticated ones (without Set-Cookie) — were stored and served from our edge cache instead of reaching your application directly.

Origin Cache-Control directives were respected where provided, and Set-Cookie response headers were not cached. However, most GET responses without explicit cache headers were cached by default during this window.

Users with domains affected by this incident will be notified via e-mail shortly.

We have already rolled out the following:

• Additional tests for correct/incorrect caching behaviors before changes are in production
• Aggressive shard-ing of CDN rollouts over hours as opposed to minutes

We apologize for this incident. Domains with CDN disabled should never have content cached. We're treating this as a trust boundary violation and are putting the safeguards in place to ensure it doesn't happen again.