Railway secret exposure: rotate keys if you host anything there

If you host a personal bot, a side project, or a small app on Railway, treat October 21, 2026 as a secrets day. Railway published a security disclosure after detecting anomalous activity around systems that store customer environment variables. Their investigation so far says an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents.

Environment variables are where people stash API keys, database passwords, and registry credentials. If those were readable, assume they need new values.

Plenty of home developers and hobbyists keep Stripe keys, OpenAI keys, Postgres URLs, and GitHub tokens in Railway. Those are the credentials that matter here.

What Railway said

From Railway’s October 21 disclosure (Jacob Cooper):

• Anomalous activity hit systems that store customer environment variables.
• An unauthorized third party may have accessed encrypted variables and, for some, the decrypted contents.
• Variables can include API keys and database or registry credentials.
• Railway believes this fits a broader set of attacks aimed at platform companies in order to reach AI inference providers, and says it notified those upstream providers to revoke keys proactively.
• Initial analysis suggests impact may be limited to a subset of users, but Railway still recommends all users take the precautions below.
• Affected customers will be contacted by email as accounts are confirmed.
• Updates continue on the blog post and on status.railway.com.

What Railway told everyone to do immediately:

1. Roll (rotate) all environment variables, including API keys stored in Railway.
2. Rotate private registry credentials.
3. Review logs for those services for unusual activity.

At disclosure time, all deployments were paused while Railway investigated. You could not roll out new versions until builds came back.

What changed after the first notice

Railway’s status incident and follow-up guides fill in the operational pieces:

• Storage bucket credentials were revoked and regenerated by Railway (your audit log shows these with the actor type Railway Staff and the name of Railway engineer Faraz Patankar). Bucket names, endpoints, and objects stay; the old ACCESS_KEY_ID / SECRET_ACCESS_KEY pairs stop working. Services need a redeploy to pick up new values (bucket / GitHub guide).
• GitHub tokens Railway held for account connections were invalidated. GitHub registry tokens stored on services were removed from Railway. Those GitHub tokens may still work on GitHub until you revoke them. Reconnect GitHub yourself, and replace ghcr.io tokens.
• On October 22 at 04:17 UTC (12:17 a.m. Eastern), Railway said it invalidated all Railway API tokens. Create new ones if you use the Public API.
• Builds returned in stages. As of Railway’s 12:30 UTC status update on October 22 (8:30 a.m. Eastern), builds were available again for Pro and Enterprise, with Hobby, then Free and Trial still waiting. Check the live status page for your plan before you assume you can redeploy.

Railway also published provider-specific checklists (OpenAI, Anthropic, Grok, OpenRouter, Stripe, AWS, GCP, GitHub, Postgres, MySQL, MongoDB, Redis). Use the ones that match secrets you actually stored.

Practical checklist for a personal Railway project

Do the secret work even if builds are still paused on your plan. Redeploy when status says your tier can build again.

1. List every variable on each service (and shared variables). Anything that looks like a key, token, password, or connection URL gets a new value at the provider first.
2. Revoke at the source, then paste the new value into Railway:
   • AI keys (OpenAI, Anthropic, and similar): delete the old key in the provider dashboard, create a new one, update Railway, redeploy when you can.
   • Stripe: rotate the secret and restricted API keys you stored, plus any webhook signing secrets, then check Stripe’s request logs for the old key.
   • AWS / GCP keys you pasted into Railway: deactivate or disable the old key, create a replacement, review cloud audit/billing for surprise spend (AWS guide, GCP guide).
   • GitHub: revoke old PATs used for registry pulls, reconnect the Railway GitHub app/account, confirm repos still deploy (bucket / GitHub guide).
3. Rotate Railway databases you use (Postgres, MySQL, MongoDB, Redis) with Railway’s Regenerate flows so the DB password and the service variables stay in sync. Then redeploy every service that connects.
4. Create a new Railway API token if anything outside Railway talks to Railway’s API. The October 22 invalidation killed the old ones.
5. Redeploy services after variables change (when builds work for your plan). Containers read variables at startup. Editing a variable without a new deploy leaves the old secret in the running process.
6. Read logs and billing for the exposure window: weird deploy activity, auth failures, AI spend spikes, cloud resources you did not create, Stripe charges you do not recognize.

If you only used Railway for a static demo with no secrets, you still should confirm there were no forgotten keys in Variables. Empty is fine. Forgotten is not.

How this fits next to other home security chores

Rotating cloud secrets is the same habit as rotating a leaked password manager entry. If this incident is how you learned you had live Stripe and OpenAI keys living in one hobby workspace, that is useful pain. Keep a short inventory of where each key lives. For device and browser secrets on your own PC, our notes on browser-saved passwords and browser extension risk are still the everyday layer.

Do this / don’t do that

Do

• Rotate every API key and database URL that lived in Railway Variables.
• Revoke GitHub PATs that were stored as registry credentials, then create new ones.
• Watch status.railway.com for when your plan can build again.
• Redeploy after secret changes so running containers stop using old values.
• Check provider usage and cloud billing for surprise activity.

Don’t

• Do not wait for a personal “you were affected” email before rotating. Railway asked all users to take precautions.
• Do not edit only the Railway variable and leave the old key alive at OpenAI, Stripe, AWS, or GitHub.
• Do not spam Redeploy while the queue is already backed up. Railway asked people not to trigger the same deployment repeatedly.
• Do not treat today’s scope as final. Railway says it is still narrowing down which accounts were affected and will email those customers directly.

Bottom line

Railway’s October 21 disclosure says encrypted customer environment variables may have been accessed, and some may have been decrypted (Railway blog). If you host anything there: rotate keys at every provider, rotate database passwords, reconnect GitHub, replace Railway API tokens, review logs and bills, then redeploy when your plan’s builds are back. Hobby projects get breached the same way production apps do when secrets sit in env vars.

Image: Railway blog header art for “Security Disclosure: Wednesday October 21st” (blog.railway.com).