30-minute key triage after your hosting platform reports a security incident

When your hosting platform says environment variables may have been exposed, assume every secret stored there could be in someone else's hands. This guide gives you an ordered 30-minute checklist, a table of where each major provider lets you revoke keys and check for misuse, and a short list of ways to make the next incident cheaper.

Every procedure in the provider table comes from that provider's own documentation, checked on 2026-10-24. Dashboards change, so follow the linked source if a menu has moved. We haven't run these procedures ourselves. This page has no affiliate links.

Why now: what Railway has officially said

On October 21, 2026, Railway published a security disclosure, followed on October 22 by a preliminary report. Railway calls this a security incident. Railway's posts say the following (forensics are still ongoing):

What was accessed: An unauthorized third party gained access to a subset of internal Railway systems. Railway says the party accessed encrypted customer environment variables and, for a subset, obtained the decrypted contents. Railway notes that environment variables may contain API keys and database and registry credentials.
Timeline: Railway believes the attack ran from October 20, 13:58 UTC to October 22, 03:32 UTC. The end time is when Railway confirmed the attacker no longer had access to internal systems.
Scale: At most 1.85% of workspaces (about 100,000) had some environment variables potentially compromised. Railway says it can't tell exactly which variables were decrypted. Its forensics point to higher risk for workspaces with very many environment variables and for environments with many AI-vendor keys.
Motive (Railway's assessment): The attacker was likely after AI and platform API keys, which Railway says were wanted for distillation attacks.
What Railway did: Paused builds and deployments (running services stayed online). Asked GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Stripe and others to revoke potentially compromised keys. Revoked all login sessions and Railway access tokens. Reset storage-bucket credentials and the GitHub tokens Railway held. Railway says a revocation email from a vendor *does not imply* your credential was actually affected.
Not affected, per Railway: Railway user accounts were not logged into. Railway has not yet ruled out access to user source code and says it will confirm in its final report.
What Railway recommends: All customers who signed up before October 21 should rotate keys stored on Railway. Roll all environment variables, including private registry credentials, and review those services' logs for unusual activity. Remove public network access to databases. Check GitHub audit logs and installed app access, and check audit logs at registries such as Docker Hub. Railway also published follow-up guides, for example on anomalous AWS access and on redeploying buckets and reconnecting GitHub.

Railway's own updates and status.railway.com are the authoritative source. The checklist below applies to any host, not only Railway.

The 30-minute checklist

Minute 0–5: Inventory every secret the host had. Export or list the environment variables for every project, service and environment on the affected platform, including preview and staging environments. Include private registry credentials, webhook signing secrets and anything a build step reads. Write down each secret's provider and what it can reach. Don't paste secret values into chats, tickets or shared docs while you do this.

Minute 5–8: Rank them by blast radius. Rotate first whatever can cost you the most, fastest: 1. Cloud root or broad IAM credentials (AWS access keys), plus database superuser passwords and connection strings. 2. Payment keys (Stripe secret or restricted keys). 3. AI provider keys (OpenAI, Anthropic, Gemini). Attackers resell these and can run up charges quickly, and Railway says they were what this attacker was after. 4. Source-control and deploy tokens (GitHub, Vercel, Cloudflare), which can become a supply-chain foothold. 5. Messaging and email keys (Twilio, Resend, SendGrid), which can be used for spam or phishing in your name.

Minute 8–20: Rotate, using create-then-revoke where you can. For each secret, create the replacement, update it in the host's variables (or your secret manager), then revoke the old one. During an active incident, keep the overlap short. Stripe, for example, keeps a rotated key working for up to 7 days unless you choose "Now". AWS and Google both recommend *deactivating* or *disabling* the old key first so you can re-enable it briefly if something you forgot breaks. See the provider table below.

Minute 20–23: Redeploy. Most platforms inject environment variables only at deploy or startup. Vercel, for example, documents that variable changes apply only to new deployments. Redeploy every service that reads a rotated secret, and update CI, local .env files and any external tools that used the old values. Check the logs for auth errors such as InvalidClientTokenId (AWS) or 401 responses.

Minute 23–28: Look for abuse. Use each provider's usage, request-log or audit-log page (listed in the table) to compare the exposure window with your normal traffic. Look for traffic from IPs or Regions you don't use, new users, keys or roles you didn't create, unfamiliar models or endpoints, and spikes in spend or email/SMS volume. Note anything suspicious with timestamps before you delete it, then remove what the attacker created.

Minute 28–30: Put guardrails on. Turn on spend limits and alerts wherever the provider offers them. OpenAI lets you enforce a hard monthly limit, and Gemini lets you set project spend caps in AI Studio. Restrict new keys to the minimum scope, and close public network access to databases that don't need it.

Provider table: revoke, replace, redeploy, check

All rows were checked against official documentation on 2026-10-24. "Unverified" means we couldn't confirm that step in the provider's docs.

| Provider | Where to revoke | Create the new key | What to redeploy / update | Check for misuse | Sources (checked 2026-10-24) | |---|---|---|---|---|---| | OpenAI | API keys page (platform.openai.com/api-keys). OpenAI: "If you believe your key has been leaked, rotate your key immediately from the API Keys page." | Create a new project key on the same page. OpenAI recommends setting an expiration date on project keys. | Every service or job that reads OPENAI_API_KEY. OpenAI: "you will need to update your key values accordingly." | Usage page (platform.openai.com/usage). Set a monthly spend limit and turn on "Enforce a hard limit" under Organization limits. Spend alerts alone don't stop traffic. | 1 2 3 | | Anthropic (Claude API) | Claude Console > API keys (platform.claude.com/settings/keys) > ⋯ menu next to the key > "Delete API key". | Create a new key in the same Console. Anthropic recommends separate keys for dev, test and prod. | Every service that reads ANTHROPIC_API_KEY (or whatever name you use). | Logs page (platform.claude.com/logs) and Usage page (platform.claude.com/usage). Spend limits on the Billing page and rate limits on the Rate limits page (for custom-rate-limit orgs). | 1 | | Google Gemini API / AI Studio | Google's leak checklist: create the replacement first, deploy it, then disable the leaked key in the Cloud console credentials page (console.cloud.google.com/apis/credentials). Don't delete the old key until the new one is fully live. | AI Studio API Keys page (aistudio.google.com/api-keys) or the Cloud console. New AI Studio keys are created as restricted "auth keys". | Deploy your code with the new key (Google's step 2, done before disabling the old one). | "Check billing logs and API usage in the Google Cloud console." Usage is also at aistudio.google.com/usage. Project spend caps: AI Studio > Spend > Monthly spend cap (experimental, can overshoot by about 10 minutes of usage). | 1 2 | | AWS IAM access keys | IAM console > Users > user > Security credentials > Access keys > Actions > Deactivate. AWS recommends deactivating first, then deleting once you've confirmed nothing breaks. | Same tab > Create access key (each user can have two keys at once). The secret is shown only once. | Every service, CI job and local profile that has AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY. | CloudTrail > Event history (last 90 days of management events, kept per Region, so check every Region). IAM credential report and last-used info. Cost Explorer for unexpected charges. If AWS sent an irregular-activity notice, reply in Support Center. | 1 2 3 | | GitHub tokens (PATs, OAuth/App authorizations) | Settings > Developer settings > Personal access tokens > delete the token. For apps, revoke the authorization under Settings > Applications; that revokes its tokens. GitHub also documents revoking all your credentials at once if you think the account is compromised. | Settings > Developer settings > Fine-grained tokens > Generate new token. GitHub recommends fine-grained tokens and setting an expiration. | CI secrets, deploy tooling, private-registry (ghcr.io) credentials, and any host integration that needs reconnecting. | Personal security log: Settings > Archives > Security log (last 90 days). Organization audit log for org resources. | 1 2 3 | | Stripe | Dashboard > API keys > overflow menu > Rotate key. In the Expiration dropdown, "Now" deletes the old key immediately. Any other choice leaves the old key working (the default grace period is up to 7 days). | Rotating generates the replacement key, so creation is part of the same step. Stripe recommends restricted keys over unrestricted secret keys. | Every server that uses the secret or restricted key. For platform-managed Stripe keys, Stripe syncs them to the platform, but you generally still need to redeploy. | API keys page > a key > View request logs (opens Workbench request logs). Stripe also recommends auditing request logs regularly. | 1 2 | | Supabase | Settings > API Keys. Create the new secret key, swap it in everywhere, confirm, then delete the leaked secret key (can't be undone). Legacy anon/service_role JWT keys: deactivate them in the same section (reversible). | Settings > API Keys > create a new secret key. Supabase suggests one secret key per backend component. Database password: Database Settings page; Supabase-managed services pick up the new password automatically. | Every backend that holds the secret/service_role key, plus any external service that hard-codes the Postgres password. | Logs (filter by API Gateway, Postgres, Auth and other log types, plus time range). pg_stat_statements shows queries per role. | 1 2 3 | | Vercel | Account Tokens page (vercel.com/account/tokens): delete the exposed token. Tokens belong to your user account, even when they're scoped to a team or project. | Same page > create a token with the narrowest scope (account, team or project) and an expiration. | Environment variable changes apply only to new deployments, so redeploy after you update secrets stored in Vercel. | Activity Log (all plans) for team events. Audit Logs with CSV export are Enterprise-only (Team Settings > Security & Privacy > Audit Log). | 1 2 3 4 | | Cloudflare API tokens | My Profile > API Tokens (Account tokens: Manage Account > API Tokens) > ⋯ > Roll. Rolling invalidates the old secret and keeps the same permissions. You can also create a fresh token instead. | API Tokens > Create Token, using a template or custom permissions limited to specific accounts or zones. | Wrangler and CI secrets (e.g. CLOUDFLARE_API_TOKEN), plus any service calling the Cloudflare API. | Audit Logs (dash.cloudflare.com > Audit logs) for account and zone changes, retained 18 months. We couldn't confirm in the docs a per-token usage history, so look for changes you didn't make. | 1 2 3 Verified (no per-token usage view found in the docs) | | PostgreSQL (generic, self-managed or any host) | ALTER ROLE name WITH PASSWORD '...'; (or PASSWORD NULL to remove password login). Optionally set VALID UNTIL. End sessions you don't recognize with pg_terminate_backend(pid). | Same ALTER ROLE statement sets the new password. Better: one role per service, so you can rotate them one at a time. | Every DATABASE_URL / connection string that uses the role. Percent-encode special characters in URLs. | pg_stat_activity (current sessions and queries). Turn on log_connections / log_disconnections to log who connects from where. | 1 2 3 4 | | Twilio (API keys) | Console > Settings > Account settings > API keys & auth tokens > API keys tab > open the key > delete. Twilio: delete a compromised key to revoke it. Auth Token rotation: Unverified (Twilio's help article only loads with JavaScript, so we couldn't read it). | Same page > Create API key (Standard or Restricted). The secret is shown once. | Every service using TWILIO_API_KEY/SECRET (or Account SID + Auth Token). | Monitor Events resource. It logs nearly every action, including actor and source IP. | 1 2 3 Verified for API keys; Auth Token rotation Unverified | | Resend | API keys dashboard (resend.com/api-keys) > More options > Remove API key. | Same dashboard (or API/CLI) > create a key with a name, a permission and an optional domain restriction. The key value can't be viewed after creation. | Every service that reads RESEND_API_KEY. | Open the key on the API keys page to see its request count, then click the count to see that key's logs. Last-used time is shown too. | 1 | | SendGrid (Twilio SendGrid) | Settings > API Keys > action menu > Delete API Key > Confirm. Calls with the deleted key are rejected. | Settings > API Keys > Create API Key, with the minimum permissions needed. | Every service using SENDGRID_API_KEY. SendGrid's documented replace flow is delete, create, then swap the key into your code. | Email Activity Feed (30-day retention needs the Email Activity history add-on). | 1 2 | ## Prevent next time

Keep secrets in a secret manager, not just host env vars. Anthropic recommends a key management system for centralized storage, access control and audit trails. Stripe notes that a vault keeps key values out of source files, CI configuration and developer environments, gives you an audit log of every access, and supports automatic rotation and instant revocation. Google recommends a secret store such as Google Cloud Secret Manager for production. With one store, the inventory step takes minutes instead of an afternoon.
Prefer scoped, short-lived credentials. Use Stripe restricted keys, GitHub fine-grained tokens with an expiration, Vercel tokens scoped to a project, Cloudflare tokens limited to specific zones, and Twilio restricted keys. OpenAI supports expiring project keys and workload identity federation, which exchanges a trusted identity for a short-lived token so you don't store a long-lived key at all.
One key per service and environment. If only one component leaks, you rotate one key instead of all of them. Supabase and Anthropic both recommend this.
Spend limits and alerts on by default. Set hard caps where they exist (OpenAI hard spend limit, Gemini project spend cap, Anthropic spend limits) and billing alerts everywhere else (Google Cloud billing alerts, AWS Cost Explorer reviews).
Practice a rotation. Stripe recommends rotating keys periodically so you know where each key is used and can replace it at short notice. A written runbook, this page included, turns a stressful night into a 30-minute task.

---

*Sources: Railway's official blog posts linked above, plus each provider's official documentation linked in the table, all checked 2026-10-24. Railway's investigation is ongoing, so check Railway's blog and status page for updates. StackLoom AI has no affiliate relationship with any provider named here.*