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 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 Railway engineer rolled out a change causing 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, which meant potentially unauthenticated data is served to authenticated users.

This meant that, your application may have served requests for one user to a different user.

As a result, for those applications serving on Railway, your users may have seen pages intended for other users.

We take this very seriously, and detail below what happened, how we’ve addressed it, and how we’re preventing it from happening in the future.

On March 30, 2026:

• 10:42 UTC - A Railway engineer deployed a configuration update to our CDN provider. This accidentally enabled caching for domains that had CDN turned off.
• 11:14 UTC - First identification of a possible issue, based on internal information + user reports
• 11:34 UTC - The change was fully 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.

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 are deeply sorry for this grave error on our part. We have already put mitigations in place to prevent it from happening again (see below), but we realize that incidents like this damage your trust in Railway, which is of paramount importance to us.

We have been working nonstop to keep up with the surge in growth we are experiencing, but will be prioritizing safety and security over new feature development to make sure we avoid similar issues in the future