We're sorry about the unexpected OpenRouter charges, and disabling the key right away was the right move. A key first stored on Railway on November 1 was not exposed through the October 21 incident, because the attacker's access to our internal systems ended at 03:32 UTC on October 22, so values stored after that point were not at risk from it on our platform.

For the provider charges, you can submit the Report of API Provider Token Abuse form so we can advocate with the provider, and please continue contacting OpenRouter directly as well. We'll notify you of a yes or no outcome once there is one.

what about other things like DATABASE_URL and other variables , should i consider they are also compromised

The same cutoff applies to every variable. Any value first stored on Railway after 03:32 UTC on October 22, 2026 was not exposed through the October 21 incident. That includes DATABASE_URL, database passwords and other secrets.

Values that were already on Railway before that time, and have not been changed since, should be treated as potentially exposed. We're sorry for the extra work. We can't confirm whether any individual variable was accessed, so we recommend rotating them as a precaution. To rotate a credential, revoke it at the provider, create a new one, update the variable and redeploy the services that use it. Start with the most sensitive credentials.

If you use one of our standard Postgres databases, our PostgreSQL rotation guide walks through regenerating its credentials.