Railway’s Environment Variable Breach: What to Rotate First, and How to Check If Your Keys Were…

An ordered checklist for vibe-coded apps on Railway, built from Railway's October 21 disclosure and its follow-up guides, as of October 23, 2026.

If your app runs on Railway, treat every value in its Variables tab as exposed. Rotate the keys that can spend your money or reach your users' data first: AI provider keys, Stripe, and your database password. Redeploy after each change, since Railway containers only read variables at startup, then check each provider's usage logs for activity you didn't cause.

That's what Railway itself tells all users to do, even though it says the impact "may be limited to a subset of users." We built the order below from Railway's disclosure and the step-by-step guides it posted on October 22. We didn't run these steps on a live incident ourselves, so each one links to the source.

Where things stand (as of October 24, 2026)

On October 21, Railway disclosed that "an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents." Its advice is to "immediately roll all environment variables, including any API keys," plus any private registry credentials, and to review logs for unusual activity.

Railway says it believes the attack is part of "a series of attacks recently targeting platform companies with the aim of compromising AI inference providers," and that it has asked those upstream providers to revoke keys proactively. So some of your AI keys may already be dead. You still need new ones in place and a look at what the old ones did.

Builds were paused during the incident. Per Railway's status page, they came back in stages and were running on every plan by the evening of October 22, ET. New signups are still paused.

Railway says it has emailed the customers with "a very high likelihood of impact." Its preliminary incident report (October 22) says at most 1.85% of workspaces (about 100,000) may have had environment variables exposed, and that the attacker was after AI provider keys. It still tells everyone who signed up before October 21 to rotate.

Step 0: list what's in your Variables tab

Open each service, click Variables, and write down every secret. Most AI-built apps on Railway hold some mix of the ones below.

OPENAI_API_KEY, ANTHROPIC_API_KEY. A leak lets someone run up model usage on your bill. Rotate in the provider console (OpenAI API keys page, Claude Console).

STRIPE_SECRET_KEY and webhook secret. A leak allows charges, refunds, payouts and new webhook endpoints. Rotate on the Stripe Dashboard's API keys page.

DATABASE_URL, POSTGRES_PASSWORD. A leak allows reading or changing your users' data. Rotate with Regenerate in Railway's Database tab.

SUPABASE_SECRET_KEY or service_role. A leak gives full database access that skips Row Level Security. Rotate in Supabase under Settings > API Keys.

Bucket ACCESS_KEY_ID / SECRET_ACCESS_KEY. A leak allows reading or deleting stored files. Railway already reset these; you redeploy.

GitHub token (deploys, ghcr.io pulls). A leak gives access to your repos or packages. Reconnect GitHub, then revoke old tokens on GitHub.

The order below is our judgment: money first, user data second, plumbing third.

The checklist, in order

1. AI provider keys. Railway's own reason for the attack points at these. For OpenAI, Railway's guide says to delete the key from the project's API keys page (deletion "takes effect immediately"), create a new one, and copy it at once because the dashboard won't show it again.

The Anthropic guide is the same shape in the Claude Console, including a separate step for Admin keys. Railway has matching guides for Grok and OpenRouter on its engineering blog.

2. Stripe. Stripe's Rotate key option lets you pick when the old key expires. Railway's Stripe guide says to choose Now for a confirmed leak, or a short window if you need time to redeploy. Rotate every other secret and restricted key on the account too, and remember the webhook signing secret is a separate variable.

3. Your database password. If you use Railway's PostgreSQL template, click the Database tab, then Config, then Regenerate next to the password. Railway's PostgreSQL guide says this updates the password and the linked variables together and restarts the database, which drops every open session.

Don't edit POSTGRES_PASSWORD by hand, because that changes only one side. While you're there, turn off Public Access under Networking if nothing outside the project needs it. Railway has separate guides for MySQL, Redis and MongoDB.

4. Supabase, if your app uses it. The publishable or anon key is built to be public, so the one that matters is the secret or legacy service_role key.

Supabase's API keys doc says to create a new secret key, swap it in everywhere, confirm every component uses it, and only then delete the old one. For a legacy service_role key, you deactivate the legacy keys instead, which Supabase says is reversible.

5. Redeploy every service that reads a changed variable. Railway's guides say containers read variables only at startup, so an edited variable does nothing until the service redeploys. A service with a pasted connection string won't pick up a regenerated password at all. Railway suggests swapping those for reference variables such as ${{ Postgres.DATABASE_URL }}.

6. Buckets and GitHub. Railway reset these for you: the S3 credentials on every bucket and the GitHub tokens it held. Your part is to redeploy services that use buckets, reconnect GitHub in Account Settings, and check that autodeploy is still on.

If you pull private images from ghcr.io, delete the old personal access token on GitHub too. Railway removed it from its side, but the token still works on GitHub until you revoke it.

If a deploy errors after all this, the status page has a tip: you may need to disconnect and reconnect your GitHub integration, and redeploying code from before the incident won't work.

Check whether the old keys were used

Rotation stops future use. These checks show what happened before you rotated.

• OpenAI and Anthropic: open Usage, group by API key, and compare token volume and the model mix against your normal traffic. Railway's Anthropic guide flags a key you only use with one model suddenly showing another as a strong signal. The Claude Console's Logs page shows individual requests.
• Stripe: open the old key's request logs (Stripe keeps them for rotated and deleted keys), then check Payments, Payouts, connected accounts, and Webhooks for endpoints you didn't create.
• PostgreSQL: search the database's deploy logs for authentication failed, and look for roles you didn't create. Railway's guide includes the SQL for both.
• GitHub: Railway's GitHub guide points to your security log (90 days), authorized OAuth apps, SSH keys and personal access tokens.
• Railway: workspace admins can review the audit log for variable reads and deployments your team didn't make. Railway's own resets show up there with the actor type Railway Staff.

If you find usage you didn't create, save the evidence before you clean up, then contact that provider's support.

Should you move off Railway?

Moving doesn't undo the exposure. Every key above needs rotating whether you stay or go, so do the checklist first.

If you decide to move afterward, Render runs web services, background workers, cron jobs and Postgres, so it's the closest swap for a backend with a database. Vercel runs server-side code as functions rather than always-on servers, which suits Next.js apps.

Railway's preliminary report puts an upper bound on scope (at most 1.85% of workspaces), but it still tells every pre-October 21 signup to rotate. New signups are paused and the support site has been down, so if you're deciding whether to stay, weigh that alongside the checklist above.

For a wider look at hosts, our guide to deploying your app compares the options for apps with a server and a database.

FAQ

What happened at Railway? On October 21, 2026, Railway disclosed that an unauthorized party may have accessed encrypted environment variables and, for some, obtained the decrypted values. It told all users to roll every environment variable, API key and private registry credential.

Was my Railway account affected? Railway's preliminary report says at most 1.85% of workspaces (about 100,000) may have had environment variables exposed. It is emailing customers with a high likelihood of impact, and it still recommends that everyone who signed up before October 21 rotate.

Are Railway deploys still paused? No. Builds are back for all tiers (restored by the evening of October 22, ET). New signups are still paused.

Do I need to redeploy after changing a variable on Railway? Yes. Railway's guides say containers read variables only at startup, so each service using a changed variable needs a redeploy.

Did Railway reset any credentials for me? Yes. Railway reset the S3 credentials for every storage bucket and the GitHub tokens it stored. You redeploy services that use buckets and reconnect GitHub yourself.

From the Stackdrop team. Stackdrop is a directory of AI tools for builders: getstackdrop.com.