Railway said early Wednesday that it is investigating a security incident in which a service storing customer environment variables may have been accessed, and that some of the contents were decrypted. The cloud deployment platform told all users to rotate any keys and passwords stored on Railway.
Environment variables are commonly used to hold startup configuration values. Developers often keep API keys and database passwords there, which means exposure can give direct access to connected accounts and services. In its security notice, Railway said the impact may be limited to only some users, but it still asked everyone to replace all credentials stored on the platform.
Builds and deployments were halted
Railway’s status page showed service disruption beginning at 3:24 p.m. UTC+8 on Oct. 21, with builds fully paused.
An update posted at 5:59 a.m. UTC+8 on Oct. 22 said all deployments had been suspended during the investigation, including enterprise plans. Enterprise builds resumed at 11:32 a.m. the same day. Pro, Hobby, Free and Trial plans were set to return in sequence, but as of noon on Oct. 22 they were still waiting.
A separate update at 12:00 p.m. said the Redeploy feature was temporarily unavailable. Users were told to open the service page, press Ctrl or Cmd plus K, and choose Deploy Latest Commit.
Railway’s recommended response
Railway said users who received notification emails, or those who wanted to act out of caution, should follow a three-step order: revoke old credentials, create new ones, then redeploy.
First, users should go to each provider’s management page and delete or disable old keys before generating replacements. Railway specifically listed Anthropic, OpenAI, OpenRouter, Stripe and GitHub.
Second, users should update the environment variables in Railway with the new values.
Third, they need to redeploy. Railway said containers only read environment variables at startup, so new values will not take effect without a fresh deployment.
Usage checks matter after rotation
Railway also told users to review usage after rotating keys and to inspect activity grouped by key. If a key that was previously used for a single model suddenly shows requests to other models, that should be treated as a warning sign.
It singled out OpenRouter as a particularly direct risk. A leaked OpenRouter key can immediately consume a user’s prepaid balance, and whoever has the key can call any model available to it. Railway said new keys should have spending caps and expiration dates.
For Anthropic, Railway said that if a user has already received a notice from the company, that key has been disabled. Even so, the user still needs to deploy a new key and review usage, according to Railway’s guidance.
Database passwords should be regenerated
Railway said database passwords should be regenerated through the database service page using the Regenerate function. That process restarts the database and cuts off all active connections, including any connection an attacker may still have open.
The company added that if a database has Public Access enabled, a leaked password can be used from anywhere on the internet. Users who do not need that setting should turn it off.
Some users said rotating keys broke their services
Because deployments were paused during the investigation, some users could not immediately complete the final step after replacing credentials.
One user on Hacker News complained that after following the advice and rotating keys, the service went down, asking: 「Which is worse, stolen keys or a broken product?」
Railway linked the incident to a broader run of attacks
Railway said the case was one of a recent series of attacks targeting deployment service providers, with the goal of breaking into AI inference vendors, or companies that provide model access. It also said it had notified those upstream providers to proactively revoke all keys.
The company did not name other providers. It also did not confirm whether this incident was carried out by the same actor behind recent cases involving Zeabur and OpenCode.
Zeabur said in an incident report published on Oct. 20 that attackers used leaked internal credentials to gain access on Oct. 14 and 15, mainly looking for directly usable API keys, especially keys tied to AI services. OpenCode said on X on Oct. 17 that a security incident the previous night affected 1.4% of Console users and may have exposed external keys stored in cloud workspaces, including keys for OpenAI, Anthropic and Google.
What is clear is that the three incidents happened within less than 10 days of each other, and all involved AI keys stored by developers in cloud environments.
Key questions remain unanswered
Railway has not yet explained at least four points: how the attacker got in, how encrypted environment variables were decrypted, how many accounts were affected, and which AI service providers were notified.
The company said it would send emails to affected accounts one by one after confirming the scope.
Timing of notifications drew criticism
Some users also criticized the timing of Railway’s communications. The blog post carried a publication time of 4:44 a.m. on Oct. 22. At 5:11 a.m., Postiz founder Nevo David wrote on X that his team was shutting down Postiz for all customers after receiving notices from Anthropic and Stripe saying keys had been exposed, while Railway 「refuses to tell us」.
Railway’s official X account posted an emergency notice at 5:51 a.m. The status page did not mention the security notice until 5:59 a.m.
Until more details are released, the safer assumption is to treat every key stored on Railway as exposed and complete the revoke, replace and redeploy process.